Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!mcsun!hp4nl!botter!star.cs.vu.nl!maart
From: maart@cs.vu.nl (Maarten Litmaath)
Newsgroups: comp.unix.ultrix
Subject: Re: Ultrix 3.0 changed basename(1)
Message-ID: <3085@solo6.cs.vu.nl>
Date: 28 Aug 89 22:13:27 GMT
References: <1989Aug25.144051.11467@acd4.UUCP> <3074@solo4.cs.vu.nl> <1458@riscy.dec.com>
Organization: V.U. Informatica, Amsterdam, the Netherlands
Lines: 32

frank@riscy.dec.com (Frank Wortner) writes:
\In article <3074@solo4.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
\=mjb@acd4.UUCP ( Mike Bryan          ) writes:
\=\It seems basename() now does some limited regular expression handling.
\=\Therefore, the command "basename /vmunix .x" will produce "vmun",
\=\rather than the expected "vmunix".  [...]
\=
\=To whoever made this change: the abovementioned behavior is COMPLETELY
\=DISTURBED!  It's like: in Ultrix 3.0 the kernel will reside in /bin/cat!
\=Use /etc/fsck to catenate files. :-(
\
\If you are as upset as your message seems to indicate, let me ask:
\Has anyone submitted an SPR regarding this problem?  That is the way
\bugs get reported.

Let me clarify.  We don't use Ultrix at all!  So don't expect a bug report
from me, other than in comp.unix.ultrix.
On the change: the regular expression addition is a good idea IN PRINCIPLE.
However, instead of making it the DEFAULT (is there a way to turn it off?),
the implementors should have added an option like `-e', that is

	$ basename -e /vmunix .x
	/vmun
	$ basename /vmunix .x
	/vmunix

Another possibility is a NEW program, like `ebasename', for Extended basename.
This utility could be a link to the old `basename', which would check its
argv[0] to find out the intended behavior.
-- 
C, the programming language that's the same |Maarten Litmaath @ VU Amsterdam:
         in all reference frames.           |maart@cs.vu.nl, mcvax!botter!maart