scs@hstbme.mit.edu (Steve Summit) (09/25/89)
In article <15@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >I won't say what I'd like >to do to the geniuses who decide that commands like ls should behave >differently for user 0 than for all other users. Let's just say that >it has on occasion had some very unpleasant consequences, which wouldn't >have happened if it had ignored the .* files like it's supposed to. >It's especially annoying to think that the little monster wastes cpu >cycles every time it's called, just so it can do this to me.... You mean ls -A is implicit if getuid() returns 0? Funny, I'd never noticed. I _like_ -A; I've essentially got ls aliased to always include it. I've never understood why there would be certain files you never want to see, or why a simple bijection based on the first character of the filename is a useful and general selection model. Selecting a command's operands and restricting its output is what shell metacharacters and grep are for. I think ls should list my directory, not list some of my directory. ("Every function should do exactly one job, and do it well.") The shells conspire with ls to perpetuate this misguided discrimination against "dot" files: it's irritating that I have to type things like rm *~ .*~ to remove _all_ the backup files GNU emacs might have left around. Anyway, getuid() is one of the least expensive system calls known.
jmm@eci386.uucp (John Macdonald) (10/07/89)
In article <14611@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >In article <15@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >>I won't say what I'd like >>to do to the geniuses who decide that commands like ls should behave >>differently for user 0 than for all other users. [...] > >You mean ls -A is implicit if getuid() returns 0? Funny, I'd >never noticed. (Are you sure you've spent enough time as root to qualify as a wizard? :-) > I _like_ -A; I've essentially got ls aliased to >always include it. Me too, or at least I did back when I was on a Xenix system that had a Berkeley-style ls. > I've never understood why there would be >certain files you never want to see, or why a simple bijection >based on the first character of the filename is a useful and >general selection model. Selecting a command's operands and >restricting its output is what shell metacharacters and grep are >for. I think ls should list my directory, not list some of my >directory. ("Every function should do exactly one job, and do it >well.") The shells conspire with ls to perpetuate this misguided >discrimination against "dot" files: it's irritating that I have >to type things like > > rm *~ .*~ > >to remove _all_ the backup files GNU emacs might have left around. Like all things, treating .* files specially has advantages and disadvantages. Some form of special treatment *was* necessary - otherwise "rm *" would remove "." and ".."! Making the rule be "anything beginning with '.' is special" rather than "'.' and '..' are special" meant that the rule about "special" files would be extensible. (If a new release of Unix had added, for example "..." as a link to the root directory of its file system, or if any other possible extension had come along, the current rule would have continued to work without any change.) As a side benefit this rule provided the option of having files that weren't automatically displayed. >Anyway, getuid() is one of the least expensive system calls known. The expense is not the problem, the inconsistancy is the problem. Your fingers type a command, and it appears to work, but it is actually working a little bit differently than you expect, but you might not notice. What is really infuriating about the special case in "ls" (i.e. -A is turned on by default for root, off otherwise) is that the -A flag is a toggle: if you simply alias ls to "ls -A", then it *stops* displaying . files when you are root. A minor annoyance about AT&T "ls" is that it doesn't have that -A at all, with or without silly choices for defaults. Thus to see all your files, you also have to see "." and ".." (fortunately, I can ignore them without too much mental strain). -- "Software and cathedrals are much the same - | John Macdonald first we build them, then we pray" (Sam Redwine) | jmm@eci386
tale@pawl.rpi.edu (David C Lawrence) (10/07/89)
In <1989Oct6.201107.9465@eci386.uucp> jmm@eci386.uucp (John Macdonald) writes:
John> Like all things, treating .* files specially has advantages and
John> disadvantages. Some form of special treatment *was* necessary -
John> otherwise "rm *" would remove "." and ".."!
No it wouldn't. rm already does special treatment of `.' and `..'.
Some form of special treatment by shell expansion of * wasn't
"necessary" at all.
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))cpcahil@virtech.UUCP (Conor P. Cahill) (10/07/89)
In article <1989Oct7.032907.27496@rpi.edu>, tale@pawl.rpi.edu (David C Lawrence) writes: > In <1989Oct6.201107.9465@eci386.uucp> jmm@eci386.uucp (John Macdonald) writes: > John> Like all things, treating .* files specially has advantages and > John> disadvantages. Some form of special treatment *was* necessary - > John> otherwise "rm *" would remove "." and ".."! > > No it wouldn't. rm already does special treatment of `.' and `..'. > Some form of special treatment by shell expansion of * wasn't > "necessary" at all. It might not have been necessary, but it was a design decision that had to be made and I, for one, like it. Others may not like it, but that always happens with design decisions. I know that I can see all of the files that begin with a . if I want to, but most of the time I don't want to see them and dont have to. The shell glob function must match the default operation of the directory lister otherwise you will remove files that you are not aware you are removing. Once the decision was made on the directory lister, there was no real choice on the shell globber. PS -> I'm not sure which decision was made first (dir lister or shell globber) but the two must agree. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
tale@pawl.rpi.edu (David C Lawrence) (10/08/89)
In <1245@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
Conor> The shell glob function must match the default operation of the
Conor> directory lister otherwise you will remove files that you are
Conor> not aware you are removing. Once the decision was made on the
Conor> directory lister, there was no real choice on the shell
Conor> globber.
So you're saying then that the shell glob functions in a BSD universe
should check for uid 0 and expand * to all non-`.' and `..' entries in a
directory? It doesn't:
rpi# ls
.cshrc .newsrc bin.server lib src
.forward .nn bin.sun3 man
.login README etc spool
rpi# echo *
README bin.server bin.sun3 etc lib man spool src
rpi# which ls
/bin/ls
Darn those broken shells. (To be fair, Conor didn't comment on
whether ls -A for root is "the right thing", but it does not have the
consistency he addressed in the article.)
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))mrd@sun.soe.clarkson.edu (Michael DeCorte) (10/08/89)
In article <1989Oct7.032907.27496@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: >No it wouldn't. rm already does special treatment of `.' and `..'. >Some form of special treatment by shell expansion of * wasn't >"necessary" at all. how about: grep foo * cat * | foo tar -cf - * # opps grab . and .. in this one plus all the local files twice echo * | cpio -o > /dev/tape # see above sure if you want to be consistent then the shell include . files but it often (usaully?) not what you want it to do. Plus I really don't want to see the 51 .* files that I have in my ~ directory (yes I really do have 51 of them) so if you make the shell and ls list .* files I am going to has for a hidden bit in the inode. But this isn't what I really want I want the hidden bit in the directory because of the wonders of links so lets throw out the entire concept of inodes and shove it all in the directory. Hmmm this seems to make a few changes in the file system. wonder what the people at <pick your maker of Unix> will think? To see a moderately flawed but still interesting article on the argument of consistency vs. most usefull behavior see this months's CACM. -- Michael DeCorte // H215-546-0497 W386-8164 Fax386-8252 // mrd@clutx.bitnet 2300 Naudain St. "H", Phil, PA 19146 // mrd@sun.soe.clarkson.edu --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
cpcahil@virtech.UUCP (Conor P. Cahill) (10/08/89)
In article <1989Oct7.191435.26382@rpi.edu>, tale@pawl.rpi.edu (David C Lawrence) writes: > So you're saying then that the shell glob functions in a BSD universe > should check for uid 0 and expand * to all non-`.' and `..' entries in a > directory? It doesn't: Basicly yes, it should. (Just my opinion) However, I think this could break lots of existing shells, so it probably wouldn't be implemented even if somebody else thought it should be that way. > Darn those broken shells. (To be fair, Conor didn't comment on > whether ls -A for root is "the right thing", but it does not have the > consistency he addressed in the article.) I don't like it. If I wanted to see the . files I would use the -a. I don't feel that it provides any special service to have it operate differently for root. Root should know enough to use the -a when he wants to. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
peter@ficc.uu.net (Peter da Silva) (10/08/89)
Another difference in 'ls' when you're root, of course, is that you get the
owner and group displayed in the 'ls -l' listing, instead of just the owner.
This is nice, though surprising to new super-users.
How do you get this behaviour when you're NOT root? ls -g just gives the group
and not the owner.
--
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
'U`
Quote: Structured Programming is a discipline -- not a straitjacket.clewis@ecicrl.UUCP (Chris Lewis) (10/09/89)
In article <1989Oct7.032907.27496@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: >In <1989Oct6.201107.9465@eci386.uucp> jmm@eci386.uucp (John Macdonald) writes: >John> Like all things, treating .* files specially has advantages and >John> disadvantages. Some form of special treatment *was* necessary - >John> otherwise "rm *" would remove "." and ".."! > >No it wouldn't. rm already does special treatment of `.' and `..'. >Some form of special treatment by shell expansion of * wasn't >"necessary" at all. I think you missed the point. If "*" expanded to include all . files, by the principle of least surprise, then every utility would *have* to *try* to act on "." and "..". Eg: ed (oof!), cat (ugh!), tar (ouch!), and unlink (YIPES!) Special casing "." files at command interpreter level is analogous to features in a lot of other operating systems. Eg: minidisk extension 0 in VM/CMS (ala PROFILE EXEC A0). I suspect that when this portion of the file system was designed, and directory self and parent links were thought out, the idea of using the "." prefix to *generally* hide files lit the proverbial light bulb as a nice touch "serendipity-wise". Almost 20 years later it still sounds like a good idea.... Special casing "ls -A" for root is a botch though. -- Chris Lewis, Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo, uunet!attcan!lsuc, yunexus}!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Phone: (416)-294-9253
tale@pawl.rpi.edu (David C Lawrence) (10/09/89)
In <1989Oct7.032907.27496@rpi.edu> I <tale@pawl.rpi.edu> wrote in
response to Michael's claim that special treatment of shell expansion
of * was necessary to not include . files so that rm wouldn't remove
`.' and `..'.
In <MRD.89Oct7205748@sun.clarkson.edu> mrd@sun.clarkson.edu (Michael DeCorte):
Michael> how about:
Michael> grep foo *
Michael> cat * | foo
Michael> tar -cf - * # opps grab . and .. in this one [...]
Michael> echo * | cpio -o > /dev/tape # see above
How about them? This whole thing is an outgrowth of, "I want to see
all files but not `.' and `..'" and the combined conspiracy (in Steve
Summit's words) of ls and shell globbing to hide .files. What about
when I do want to grep all of the files (but not . and ..) in the
current directory? Shell globbing alone is not sufficient for this
where .files exist.
Michael> sure if you want to be consistent then the shell include . files
Michael> but it often (usaully?) not what you want it to do.
Yes, often. I am not so sure about usually though. Except in my own
home directory, I usually want to know what all the entries in a
directory are.
Michael> Plus I really don't want to see the 51 .* files that I have in my ~
Michael> directory [...]
I think Steve Summit <scs@hstbme.mit.edu> had a very good comment
about this in <14611@bloom-beacon.MIT.EDU>. I agree with most of his
comments in the article.
Steve> I've never understood [...] why a simple bijection based on the
Steve> first character of the filename is a useful and general
Steve> selection model.
Dave
--
(setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))peter@ficc.uu.net (Peter da Silva) (10/09/89)
In article <1989Oct8.212100.12355@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: >What about >when I do want to grep all of the files (but not . and ..) in the >current directory? Shell globbing alone is not sufficient for this >where .files exist. grep 'pattern' .??* * -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' 'U` Quote: Structured Programming is a discipline -- not a straitjacket.
rli@buster.irby.com (Buster Irby) (10/09/89)
peter@ficc.uu.net (Peter da Silva) writes: >In article <1989Oct8.212100.12355@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: >>What about >>when I do want to grep all of the files (but not . and ..) in the >>current directory? Shell globbing alone is not sufficient for this >>where .files exist. >grep 'pattern' .??* * Sorry Peter, but you just flunked your Unix Wizards Test! The '.??*' you mentioned above will not only exclude '.' and '..' from the glob, but will exclude all '.?' files such as ".a", ".B", from the glob as well. If you are using the Bourne or the Korn shell, you can try this instead: grep 'pattern' .[!.]* ..?* * The middle pattern '..?*' is only needed if you are in the habit of creating hidden files with two or more leading dots instead of just one, such as '..a' or '..B', otherwise it can be excluded. -- Buster Irby buster!rli
rli@buster.irby.com (Buster Irby) (10/09/89)
peter@ficc.uu.net (Peter da Silva) writes: >Another difference in 'ls' when you're root, of course, is that you get the >owner and group displayed in the 'ls -l' listing, instead of just the owner. >This is nice, though surprising to new super-users. >How do you get this behaviour when you're NOT root? ls -g just gives the group >and not the owner. Peter, you must be using a different ls than the rest of us. ls -l under System V/386 gives you both the user id and group id regardless of who you are. from ls(1) - Unix System V/386 -l List in long format, giving mode, number of links, owner, group, size in bytes, and time of last modification for each file. If the file is a special file, the size field will instead contain the major and minor device numbers rather than size. -o Same as -l except that group is not printed. -g Same as -l except that owner is not printed. This is true of ls(1) on both the System V/386 and standard System V as distributed on AT&T 3B2 machines. You must be confusing Unix behavior with Xenix behavior, and they are not the same. -- Buster Irby buster!rli
peter@ficc.uu.net (Peter da Silva) (10/09/89)
I said, > grep 'pattern' .??* * Would exclude . and .. from a search. In article <602@buster.irby.com> rli@buster.irby.com (Buster Irby) writes: >Sorry Peter, but you just flunked your Unix Wizards Test! And goes on to point out that I'm skipping all 2-character names beginning with '.', like '.a' for example. Yes, I know that. But in practical terms '.??* *' is good enough, and a lot easier to type. I can't recall ever seeing a file that would match '.?'. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' 'U` Quote: Structured Programming is a discipline -- not a straitjacket.
cpcahil@virtech.UUCP (Conor P. Cahill) (10/09/89)
In article <6468@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <1989Oct8.212100.12355@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: > >What about > >when I do want to grep all of the files (but not . and ..) in the > >current directory? Shell globbing alone is not sufficient for this > >where .files exist. > > grep 'pattern' .??* * This doesn't handle the case of the .[single letter that is not a dot] case. On system V you could use: grep 'pattern' .[!.]* ..?* * -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
peter@ficc.uu.net (Peter da Silva) (10/09/89)
[ls -l gives owner+group only when su-root] In article <603@buster.irby.com> rli@buster.irby.com (Buster Irby) writes: >Peter, you must be using a different ls than the rest of us. ls -l >under System V/386 gives you both the user id and group id regardless >of who you are. System V/386 isn't the whole world. Not only is there BSD, but there are lots of systems running System-III derived Xenix. Like me. >System V as distributed on AT&T 3B2 machines. You must be confusing >Unix behavior with Xenix behavior, and they are not the same. Sorry, Buster. Xenix *IS* UNIX. Xenix *IS* UNIX. So is V7 UNIX, BSD UNIX, System III, Version 6, PWB, Onyx, TNIX, Venix, etcetera, etcetera, etcetera. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' 'U` Quote: Structured Programming is a discipline -- not a straitjacket.
jfh@rpp386.cactus.org (John F. Haugh II) (10/10/89)
In article <6470@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <602@buster.irby.com> rli@buster.irby.com (Buster Irby) writes: >>Sorry Peter, but you just flunked your Unix Wizards Test! ... >Yes, I know that. But in practical terms '.??* *' is good enough, and a >lot easier to type. I can't recall ever seeing a file that would match >'.?'. The most common name for a command to give a user quick and easy password free access to root is '.s'. I've seen this same scheme, a '.', followed by a single character, used to name all manner of files people aren't supposed to see. % ls -l /usr/jfh/src/c/.s.c -rw-r--r-- 1 jfh root 142 Oct 3 13:43 /usr/jfh/src/c/.s.c Compiled this becomes '.s'. % ls -la /mnt total 36 drwxrwxrwx 2 root root 64 Oct 3 13:38 . drwxr-xr-x 13 root root 512 Oct 9 08:48 .. -rwsrwxrwx 1 root root 13719 Oct 3 13:44 .s -rw-r--r-- 1 jfh root 59 Oct 3 13:38 .s.c Hmmm. You flunked -really- bad this time. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of MACH is ... InterNet: jfh@rpp386.cactus.org | ... Messages Are Crufty Hacks. UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
dan@dsi.COM (Dan Mick) (10/10/89)
In article <6466@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Another difference in 'ls' when you're root, of course, is that you get the >owner and group displayed in the 'ls -l' listing, instead of just the owner. > >This is nice, though surprising to new super-users. > >How do you get this behaviour when you're NOT root? ls -g just gives the group >and not the owner. ls -lg
guy@auspex.auspex.com (Guy Harris) (10/10/89)
>Another difference in 'ls' when you're root, of course, is that you get the >owner and group displayed in the 'ls -l' listing, instead of just the owner. > >This is nice, though surprising to new super-users. > >How do you get this behaviour when you're NOT root? ls -g just gives the group >and not the owner. You replace whatever Mutant UNIX From Hell you're running with one that offers an "ls" that's either more like vanilla S5 or vanilla 4.xBSD than the one you have, and: 1) if it's more like vanilla S5, just do "ls -l", and get the owner and group *regardless* of the UID under which it's running; 2) if it's more like vanilla 4.xBSD, just do "ls -lg", and get the owner and group *regardless* of the UID under which it's running.
merlyn@iwarp.intel.com (Randal Schwartz) (10/10/89)
In article <6468@ficc.uu.net>, peter@ficc (Peter da Silva) writes: | In article <1989Oct8.212100.12355@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: | >What about | >when I do want to grep all of the files (but not . and ..) in the | >current directory? Shell globbing alone is not sufficient for this | >where .files exist. | | grep 'pattern' .??* * Nope. Misses the two character files beginning with dot. And, whatareyagonna do about that? :-) I still like: grep 'pattern' `ls -A` but that presumes you're in a place that understands -A. Just another UNIX hacker, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
peter@ficc.uu.net (Peter da Silva) (10/10/89)
In article <17116@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: > The most common name for a command to give a user quick and easy > password free access to root is '.s'. I've never seen that one. I have run into one called /usr/lib/tmac/tmac.z, though. That was amusing. > I've seen this same scheme, > a '.', followed by a single character, used to name all manner of > files people aren't supposed to see. So? I'm not suggesting making .? invisible to 'ls -A' or anything like that. I'm just pointing out that, *for most purposes*, when you want to do something with all the files other than . and .. it's quick and easy to use .??* to match them all. Personally, I look for trapdoors with things like 'find' rather than 'echo *'... but I'm thankful for the insight into how you maintain your C2 secure systems. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' 'U` Quote: Structured Programming is a discipline -- not a straitjacket.
cpcahil@virtech.UUCP (Conor P. Cahill) (10/10/89)
In article <603@buster.irby.com>, rli@buster.irby.com (Buster Irby) writes: > peter@ficc.uu.net (Peter da Silva) writes: > > >Another difference in 'ls' when you're root, of course, is that you get the > >owner and group displayed in the 'ls -l' listing, instead of just the owner. > > Peter, you must be using a different ls than the rest of us. ls -l > under System V/386 gives you both the user id and group id regardless > of who you are. If you had been reading this thread, you would know that the discussion was about the differnces with BSD's ls when root runs it. (one of them noted above, but the original note was reguarding the -A flag) so the example of your system V doesn't apply. Although I also run System V (and prefer it over BSD, in general), I do not think that "the rest of us" do. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
jfh@rpp386.cactus.org (John F. Haugh II) (10/10/89)
In article <6471@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Sorry, Buster. Xenix *IS* UNIX. Xenix *IS* UNIX. So is V7 UNIX, BSD UNIX, >System III, Version 6, PWB, Onyx, TNIX, Venix, etcetera, etcetera, etcetera. Beg to differ. UNIX(tm) is a registered trademark for a product which AT&T sells. It is -not- any operating system which wishes to call itself UNIX. Xenix is -not- UNIX. BSD 4.x is -not- UNIX. Nor are the remainder of the things listed above which can't legally call themselves UNIX. There really is a good reason for this. The entire reason the SVID and SVVS and friends exist is to define exactly -what- UNIX really is. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of MACH is ... InterNet: jfh@rpp386.cactus.org | ... Messages Are Crufty Hacks. UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
steve@nuchat.UUCP (Steve Nuchia) (10/10/89)
In article <17118@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>System III, Version 6, PWB, Onyx, TNIX, Venix, etcetera, etcetera, etcetera. >Beg to differ. UNIX(tm) is a registered trademark for a product which >AT&T sells. It is -not- any operating system which wishes to call itself >UNIX. Meeeeeep! AT&T sold each of v7, sysIII, and sysV in turn under the name UNIX. If it was called Unix then but isn't called Unix now, what exactly is it called now? >There really is a good reason for this. The entire reason the SVID >and SVVS and friends exist is to define exactly -what- UNIX really is. Then we are in serious trouble. Have you actually tried to *read* the SVID? I suppose you (John) have, but most people haven't. Good thing too, very few people are strong enough to resist permanant scarring from exposure to it. Unix is the legacy of a bunch of hard work by many people, some of whom worked for AT&T while doing some of that work. AT&T owns the trademark but they don't own Unix. If they did they wouldn't have spent all that time and energy on the SVID, which is an effort to reclaim Unix. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 270249 Houston, Texas 77277 (713) 964 2462 Consultation & Systems, Support for PD Software.
guy@auspex.auspex.com (Guy Harris) (10/11/89)
>On system V you could use: > > grep 'pattern' .[!.]* ..?* * More precisely, under the System V Bourne shell you could use the above. Some systems that advertise themselves as System V include the C shell, and probably don't support the "!" operator in the C shell, and some systems not thought of as System V systems have a System V Bourne shell as their Bourne shell.
jik@athena.mit.edu (Jonathan I. Kamens) (10/11/89)
In article <602@buster.irby.com> rli@buster.irby.com (Buster Irby) writes: =peter@ficc.uu.net (Peter da Silva) writes: = ==grep 'pattern' .??* * = =Sorry Peter, but you just flunked your Unix Wizards Test! The ='.??*' you mentioned above will not only exclude '.' and '..' =from the glob, but will exclude all '.?' files such as ".a", ".B", =from the glob as well. If you are using the Bourne or the Korn shell, =you can try this instead: = =grep 'pattern' .[!.]* ..?* * = =The middle pattern '..?*' is only needed if you are in the habit of =creating hidden files with two or more leading dots instead of =just one, such as '..a' or '..B', otherwise it can be excluded. Actually, ".??* *" is sufficient unless you are "in the habit of creating hidden files" matching the ".?" pattern. :-) Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-4261 Home: 617-782-0710
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/11/89)
In article <17118@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >Xenix is -not- UNIX. BSD 4.x is -not- UNIX. Nor are the remainder >of the things listed above which can't legally call themselves UNIX. BSD predates the SVID, SVVS, and rules about calling the modified AT&T software (that's what BSD basically is) "UNIX". The latest release of Xenix is called UNIX System V Release 3.2. Besides, recall what Humpty Dumpty said about who's master..
jc@minya.UUCP (John Chambers) (10/13/89)
In article <1989Oct7.032907.27496@rpi.edu>, tale@pawl.rpi.edu (David C Lawrence) writes: > In <1989Oct6.201107.9465@eci386.uucp> jmm@eci386.uucp (John Macdonald) writes: > John> Like all things, treating .* files specially has advantages and > John> disadvantages. Some form of special treatment *was* necessary - > John> otherwise "rm *" would remove "." and ".."! > > No it wouldn't. rm already does special treatment of `.' and `..'. > Some form of special treatment by shell expansion of * wasn't > "necessary" at all. Which brings up a point that seems to have been missed. The special treatment of filenames starting with '.' isn't done by the kernel; it is done by the shell. The shell isn't a hard-wired part of Unix. One of the standard rejoinders to this sort of complaint is "If you don't like the way the shell does it, write your own." Granted, there's a small bit of facetiousness in this. The Bourne shell is effectively a mandatory part of a deliverable Unix system. But the basic point still stands: The interpretation of '.' isn't done at the lowest levels; it is done at a high level, in the command interpreter, and in a few utilities like ls. It's not hard to write utilities that follow other rules. Go ahead; it's fun... -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying
jc@minya.UUCP (John Chambers) (10/13/89)
In article <1248@virtech.UUCP>, cpcahil@virtech.UUCP (Conor P. Cahill) writes: > In article <1989Oct7.191435.26382@rpi.edu>, tale@pawl.rpi.edu (David C Lawrence) writes: > > Darn those broken shells. (To be fair, Conor didn't comment on > > whether ls -A for root is "the right thing", but it does not have the > > consistency he addressed in the article.) > I don't like it. If I wanted to see the . files I would use the -a. I don't > feel that it provides any special service to have it operate differently > for root. Root should know enough to use the -a when he wants to. More to the point is that commands don't just come from people at keyboards; they also come from scripts. I've written several applications that include some special-purpose directories containing files of one type, and scripts that do things like: for f in `ls foo` do <something with each $f> done It is a good idea to include some documentation in all your directories, and management often decrees that There Will Be README Files Everywhere. I tend to agree; in the special-purpose directories, I just call it .README and all is fine. Until the script is run by a super-user, in which case the ls command above includes the .README in the list, and all hell breaks loose. I like to test things out first as an ordinary user, then turn them over to the systems' users, who will eventually run them when they are logged in as root. It's real exasperating to have something thoroughly tested and working, and get bitten by something as stupid as this. With things like this lurking in our systems, it's not at all surprising that our software is so flakey. Grumble... -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying
gil@banyan.UUCP (Gil Pilz@Eng@Banyan) (10/17/89)
In article <17118@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >There really is a good reason for this. The entire reason the SVID >and SVVS and friends exist is to define exactly -what- UNIX really is. Yeah, the only problem is that they don't work, i.e. you can be "SVID compliant" yet not pass the SVVS, or you can pass the SVVS yet not be "SVID compliant". Just a pet peeve of mine, but I hate when people throw these two out as if they really were "exact" specs/tests. -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Gilbert W. Pilz Jr. gil@banyan.com Banyan Systems Inc. (617) 898-1196 115 Flanders Road Westboro, MA 01581 -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-