> From: "Ron Natalie"
> Actually, it's the shell that calls glob.
Yes, in the initial expansion of the command line, but V6 'rm' also uses
'glob' internally; if the '-r' flag is given, and the current name in the
command argument list is a directory, viz.:
if ((buf->mode & 060000) == 040000) {
if (rflg) {
...
execl("/etc/glob", "glob", "rm", "-r",
fflg? "-f": "*", fflg? "*": p, 0);
printf("%s: no glob\n", arg);
exit();
}
(where 'p' is 0 - no idea why the writer didn't just say '"*": 0, 0').
So "rm -f foo*", where the current directory contains file 'foo0 foo1 foo2'
and directoty 'foobar', and directory 'foobar' contains 'bar0 bar1 bar2', the
first instance of 'glob' (run by the shell) expands the 'foo0 foo1 foo2 foobar'
and the second instance (run by 'rm') expands the 'bar0 bar1 bar2'.
> Glob then invokes the command (in this case rm).
I don't totally grok 'glob', but it is prepared to exec() either the command
name, /bin/{command} or /usr/bin/{command}; but if that file is not executable
it tries feeding it to the shell, on the assumption it must be a shell command
list:
execv(file, arg);
if (errno==ENOEXEC) {
arg[0] = file;
*--arg = "/bin/sh";
execv(*arg, arg);
}
I guess (too lazy to look) that the execv() must return a different error
number if the file doesn't exist at all, so it only tries the shell if the
file existed, but wasn't executable.
Noel
There was an incident at Pixar that a runaway rm ate most of the Toy Story 2
movie. The only thing that saved them was an employee had their own copy
on a machine at home.
We never lost the whole disk through one of these, but we did have a guy
wipe out /etc/passwd one day. Our password fields had an rfc-822ish user
name in the gcos field, so it looked
something like:
ron::51:50:Ronald Natalie <ron>:/sys1/ron:
Well, one of our users decided to grep for a user (alas while root) with the
command
grep <howard> /etc/passwd
Hello all.
It's off-topic for this list, but there is turmoil in Linux-land. A bug
was discovered in systemd, whereby systemd re-implemented "rm"
functionality without following POSIX "rm" behaviour. This could kill a
system, as explained here: https://github.com/systemd/systemd/issues/5644
The reference POSIX "rm" behaviour is that "rm -rf .*" should NOT delete
the current and parent directories, as stated here:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html#tag_20_11…
So, to get on-topic, I have a question for UNIX historians: when was it
first defined in the UNIX realm that "rm -r .*" should NOT delete the
current and parent directories? Would the command "cd /tmp ; rm -rf .*"
be able to kill a V6 or V7 UNIX system?
Regards,
--
Josh Good
I have a memory of having seen a Zilog Z-80 (not Z8002 like the Onyx) based Unix, possibly v6, at a vendor show or conference - perhaps the West Coast Computer Faire (WCCF) in the late 1970s or early 1980s.
I recall asking the people in the booth how they managed without an MMU, and don't recall their answer. I do remember thinking that since Unix had "grown up" with MMUs to stomp on obvious pointer mistakes, the software ought to be relatively well-behaved ... you know: not trying to play "core war" with itself?
I searched the TUHS archives cursorily with Google to see if this has been previously mentioned, but pretty much all Z80 CPU references have for its use in "smart" I/O devices back in the day.
Does anyone else remember this Z80 Unix and who did it? Or maybe that it was a clone of some kind ... ?
looking for a little history,
Erik Fair
I was trying to configure C news on 2.9BSD today and I found that its
Bourne shell doesn't grok # comments. The Bourne shell in 2.11BSD does.
So I thought: when did the Bourne (and other) shells first grok # as
indicating a comment? Was this in response to #! being added to the
kernel, or was it the other way around? And was the choice of #!
arbitrary, or was it borrowed from somewhere else?
Datum point: 2.9BSD's kernel can recognise #!, but the sh can't recognise #.
Cheers, Warren
"Shebang". Nice coinage (which I somehow hadn't heard before).
Very much in tune with Bell Labs, where Vic Vyssotsky had instilled
"sharp" as the name of # -- not "number", not "pound", and definitely
not "hash" -- so shell scripts began with sharp-bang.
Doug
Hi,
I've imaged (with ImageDisk) some floppies I've got with my "new" 8560
system.
You can find them at
ftp://ftp.groessler.org/pub/chris/tektronix/8560/diskimages .
Among other things there are cross-assemblers for 68000, 6809, and 6800.
From the TNIX installation disk set one is missing (disk 5 of 5).
I'm looking for the Z8000 cross-assembler for TNIX. Does anyone have it?
regards,
chris
Oldest actual use in a post I can find is 1997
I did find something I had completely forgot about. The csh used to (probably still does?) differentiate between Bourne shell scripts and csh scripts by looking for #.
> From: "Erik E. Fair"
> I have a memory of having seen a Zilog Z-80 .... based Unix, possibly v6
> ... I recall asking the people in the booth how they managed without an
> MMU, and don't recall their answer. I do remember thinking that since
> Unix had "grown up" with MMUs to stomp on obvious pointer mistakes, the
> software ought to be relatively well-behaved
I don't know about the Z80 part, but for the MMU aspect, recall that the first
couple of versions of PDP-11 Unix ran on a model (the -11/20) which didn't
have an MMU (although, as mentioned before here, it apparently did later use a
thing called a KS11, the specifications for which seem to be mostly lost).
Although recall the mention of calling out "a.out!", as to the hazards of
doing so...
And of course there was the 'Unix for an LSI-11' (LSX), although I gather that
was somewhat lobotomized, as the OS and application has to fit into 56KB
total.
So it was possible to 'sorta kind-of' do Unix without an MMU.
Noel
> Is this a reason why "#" was chosen as the root prompt, by the way?
No. # was adopted as superuser prompt before the shell had a
comment convention.
Doug