mjb@acd4.UUCP ( Mike Bryan ) (08/25/89)
Arrgh! I just discovered a change to basename(1) in Ultrix 3.0. My apologies if this has been posted before, but I don't recall seeing any news about this. It seems basename() now does some limited regular expression handling. Therefore, the command "basename /vmunix .x" will produce "vmun", rather than the expected "vmunix". A workaround (the new required method?) is to say "basename /vmunix \\.x". Of course this was not documented in the release notes, although the manual page does mention the blurb about RE's (but not the incompatibility!!!). The problem comes about for us because we use basename in certain Makefile entries to strip out a ".c" if it is inadvertently left on for lint checks, as in "f=`basename $f .c`.c". Of course, if $f is now something like "coproc", we're hosed. Was this done just because it would be "useful/incompatible", or was it done to match some other flavor of Unix??? Excuse me while I go change 150 million Makefiles... -- Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802 Phone: 812/232-6051 FAX: 812/231-5280 Home: 812/232-0815 UUCP: uunet!acd4!mjb ARPA: acd4!mjb@uunet.uu.net "Did you make mankind after we made you?" --- XTC, "Dear God"
maart@cs.vu.nl (Maarten Litmaath) (08/26/89)
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. :-(
--
"rot H - dD/dt = J, div D = rho, div B = 0, |Maarten Litmaath @ VU Amsterdam:
rot E + dB/dt = 0" and there was 7-UP Light.|maart@cs.vu.nl, mcvax!botter!maartfrank@riscy.dec.com (Frank Wortner) (08/28/89)
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. Regards, Frank
maart@cs.vu.nl (Maarten Litmaath) (08/29/89)
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
grr@cbmvax.UUCP (George Robbins) (08/29/89)
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. :-( Perhaps you haven't looked closely at the manual page entry for the System V implementation of basename - for better or worse, the second argument is interpreted as part of a expr(1) regular expression, with just the behavior described above. Whether such a wonderful feature should be ported to Ultrix is, of course, a different argument. The new implementation has other problems with quoting of arguments, which were reported to Software Support via DSIN around July 11 or 12, though I didn't request an SPR - in my case the workaround was obvious: just retrieve a working version of basename from the Ultrix 2.x release tape... There is also a funny error in the manpage, where it says: deletes any prefix end in a --> backslash <--. Whoever did this basename hack just wasn't having a good day, eh? -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
mjb@acd4.UUCP ( Mike Bryan ) (08/29/89)
In article <7769@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) 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". [...] >> >Perhaps you haven't looked closely at the manual page entry for the System V >implementation of basename - for better or worse, the second argument is >interpreted as part of a expr(1) regular expression, with just the behavior >described above. Well, maybe the manual page entry says that, but looking at Issue 2 of the SVID, Volume 2, page 31, it says: "The command basename deletes any prefix ending in / and the suffix (if present in string), and prints the result on the standard output." Period. Nothing about REs at all. DEC has told me on more than one occasion that a piece of software "works that way because that is the behaviour defined in the SVID." If some System V implementer has changed the functionality of basename(1) in a manner incompatible with the SVID, who is right/wrong? Furthermore, if DEC wants System V compatibility for Ultrix, then should they conform to the SVID, or should they conform to the latest version of AT&T System V? For the record, I have submitted an SPR to DEC, but have not yet received a response. -- Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802 Phone: 812/232-6051 FAX: 812/231-5280 Home: 812/232-0815 UUCP: uunet!acd4!mjb ARPA: acd4!mjb@uunet.uu.net "Did you make mankind after we made you?" --- XTC, "Dear God"
grr@cbmvax.UUCP (George Robbins) (08/30/89)
In article <1989Aug29.132003.23389@acd4.UUCP> mjb@acd4.UUCP ( Mike Bryan ) writes: > In article <7769@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) 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". [...] > >> > >Perhaps you haven't looked closely at the manual page entry for the System V > >implementation of basename - for better or worse, the second argument is > >interpreted as part of a expr(1) regular expression, with just the behavior > >described above. > > Well, maybe the manual page entry says that, but looking at Issue 2 of > the SVID, Volume 2, page 31, it says: > > "The command basename deletes any prefix ending in / and the suffix > (if present in string), and prints the result on the standard output." > > Period. Nothing about REs at all. Well, actually I noticed that also, but preferred reality to the SVID. It may be that the SVID page is screwed up, the expample shown has the '.x' quoted, which would only be neccessary if there's a backslash preceeding the '.' as in the man page example...wouldn't be the first time someone screwed up troff text and made \'s dissapear. Perhaps there's a test in the SVVS that fails without the regular expression stuff. Certainly the SVr3 system I tried it on did the silly RE stuff... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)