symbolic links are a botch
d...@ulysses.uucp
If you type
cd /usr/include/sys
echo cwd=$cwd
/bin/pwd
cd ..
echo cwd=$cwd
/bin/pwd
from csh with BSD 4.3 running on our vax you get:
cwd=usr/include/sys
/usr/sys/h
cwd=/sys
/usr/sys
If you do the equivalent
cd /usr/include/sys
/bin/pwd
echo cwd=$PWD
cd ..
echo cwd=$PWD
/bin/pwd
from the Korn shell with BSD 4.3 running on our vax you get:
cwd=/usr/include/sys
/usr/include/sys
cwd=/usr/include
/usr/include
If you do the nearly equivalent
cd /usr/include/sys
pwd
/bin/pwd
cd ..
pwd
/bin/pwd
from the 4.3 Bourne shell you get:
usr/include/sys
usr/include/sys
/usr/sys/h
/sys
I think that the reason for this discrepancy is that the implementation
of symbolic links on BSD Unix is a botch.
In order to use a system with symbolic links without being surprised,
you have to be aware of all symbolic links to directories. The reason
is that the kernel does not keep track of the device-inodes as you
descend the file tree, so it does not know how to walk back up.
For example, if I add a directory of include files named /usr/include/local
and one of my include files includes ""../stat.h", it will not work on
BSD but will work on Sys V.
Can you imagine what Unix would have been like if .. were not handled
specially at mount points? You would have to know where each of the
mount points were. Two systems could be compatible only if they had
identical mount points.
I recently added symbolic links to my version of System V Release 3
kernel. I made sure that .. was always handled like an operator that
moves you up one level. The changes were not complex and I have not
run into any problems at all. The user again sees the file system as
a tree structure which preserves the original simplicity of the Unix model.
By the way, I did modify find so that you can specify a virtual walk
or a physical walk. I virtual walk follows symbolic links. The virtual
walk keeps track of device-inodes so that I never descend through the
same physical directory more than once. Therefore, a symbolic line to
/ poses no problem.
( Now some guru might say that . and .. are just names that have
i-nodes associated with them just like any other name and therefore, the
i-node should be followed. If this were true, then as root I should
be able to edit my directory and change the inode of . to change its
meaning. What do you think really happens?)
I am conducting a poll on this issue and I am interested in hearing your views.
I will post the results to this newsgroup on the net.
What would be the best semantics for ..?
Do you think that BSD has done it right or have I done it right?
What code would break if .. were always treated as an operator?
Disclaimer: I am not affiliated with the System V product, I am involved
in research only and these are my own. They do not imply any direction
for future releases of System V.
David Korn
{ihnp4,decvax}ulysses!dgk
gw...@brl-smoke.uucp
>I recently added symbolic links to my version of System V Release 3
>kernel. I made sure that .. was always handled like an operator that
>moves you up one level.
The BRL SVR2 Bourne shell can be configured to handle symbolic links
either way insofar as "cd" and "pwd" go. I always build it to act
the way the Korn shell does, so that "cd .." never drops me into a
surprising place.
To really address this problem fully satisfactorily, however, one
does need to make the kernel keep track of the path used to reach
the current working directory, as well as have ".." handled specially.
It is no longer guaranteed that one will get the "." and ".." entries
when reading a directory (using POSIX-compatible access routines), so
if you elect to not return a ".." entry in a directory you need not
even play the tricks with its inode number needed to make the revised
".." semantics work right.
I think you (David Korn) got it exactly right. Symbolic links are
useful (thanks, Dennis!), but the deviation from strict hierarchical
directory structure was a major problem with them. A system with
a sensible notion of current working directory such as you appear to
have would be best. Please send the work to the Summit folks so we
can get good symlink support into SVRn (n > 3.1).
Root Boy Jim
I think that the reason for this discrepancy is that the implementation
of symbolic links on BSD Unix is a botch.
I think the key word here is "the". The kernel implements symbolic
links as you describe below; the csh maintains $cwd symbolicly. If you
do `cd /foo/bar' where /foo/bar -> /whiz/bang followed by `cd ..',
$cwd gives /foo while pwd gives /whiz. Thus csh is interpreting `..'
to mean `back' while the kernel takes it to mean `up'.
In order to use a system with symbolic links without being surprised,
you have to be aware of all symbolic links to directories. The reason
is that the kernel does not keep track of the device-inodes as you
descend the file tree, so it does not know how to walk back up.
As you mention, the kernel has no sense of history (is it thus condemned
to repeat it? :-), whereas the csh does. This is mentioned in the bugs
section.
For example, if I add a directory of include files named /usr/include/local
and one of my include files includes ""../stat.h", it will not work on
BSD but will work on Sys V.
Can you imagine what Unix would have been like if .. were not handled
specially at mount points? You would have to know where each of the
mount points were. Two systems could be compatible only if they had
identical mount points.
It would be like Version 6, right? I think `cd ..' didn't work at
the `root' of a mounted file system.
I recently added symbolic links to my version of System V Release 3
kernel. I made sure that .. was always handled like an operator that
moves you up one level. The changes were not complex and I have not
run into any problems at all. The user again sees the file system as
a tree structure which preserves the original simplicity of the Unix model.
There is no way you can simulate a tree unless you ignore symbolic links,
because it no longer *is* a tree. It is a directed graph, possibly with
loops. In fact, symbolic links are no worse than when root makes links
between directorys. The possibility exists for loops, and the notion of
`up' is relative to the original directory, because it was made with
mkdir, which created the `..' entry, whereas the replicant was made
exactly like a regular link, merely adding an entry in *it's* parent
directory and bumping the target inode link count. It remains childless,
in the sense that it is no one's parent.
By the way, I did modify find so that you can specify a virtual walk
or a physical walk. I virtual walk follows symbolic links. The virtual
walk keeps track of device-inodes so that I never descend through the
same physical directory more than once. Therefore, a symbolic line to
/ poses no problem.
What you do with find has nothing to do with what the kernel thinks.
Find's job is to make some sense out of `everything in this subtree',
while the kernel only cares how to get from here to there, one level
at a time. Ignoring symbolic links turns the graph back into a tree;
consider what tar does with symbolic links. It merely records their
presence; it does not descend into any subdirectorys or recopy any files.
Alternatively, considering them as first class citizens can flatten
a graph into a tree (with various files or subdirectorys replicated
as long as there are no loops). There are useful interpretations for both.
( Now some guru might say that . and .. are just names that have
i-nodes associated with them just like any other name and therefore, the
i-node should be followed. If this were true, then as root I should
be able to edit my directory and change the inode of . to change its
meaning. What do you think really happens?)
Whoa! It is a long way from playing with the meaning of . and .. to
editing directory as if they were files. Consider the `link' and
`unlink' programs, main(c,v)char**v;{link(v[1],v[2]);} and
main(c,v)char**v;{unlink(v[1]);} respectively. Now try `unlink .'
followed by `link . <something random>' followed by `cd .' followed
by `/bin/pwd'. Don't be surprised if you get something random. Similarly
for `..'. The kernel doesn't give a hoot, but you and I and fsck do.
What would be the best semantics for ..?
Exactly what they are now as far as the kernel is concerned.
Do you think that BSD has done it right or have I done it right?
At the next conceptual level, i.e. that of the shell, i.e. what
happens when you type `cd ..', I can see several alternatives.
Possibly the best is to not treat it specially. Alternately, one
could consider it to be "rindex(cwd,'/')[0]=0; chdir(cwd)".
What code would break if .. were always treated as an operator?
What do you mean by operator? `UP', or `BACK'? Or something else?
consider the case of loops, where after `descending' into the same
directorys a few times and realizing what happened, do you want to
retrace your steps in reverse, or go straight up as fast as possible.
In the former case, `..' has a time dependent meaning.
Disclaimer: I am not affiliated with the System V product, I am involved
in research only and these are my own. They do not imply any direction
for future releases of System V.
Likewise :-)
Perhaps I can sum up by saying that symbolic links are fraught with
paradoxes; that even their creators have not addressed. They are much
like trap doors. However, they are useful enuf to be suffered their
anomalys. I hope I can live up to that standard.
David Korn
{ihnp4,decvax}ulysses!dgk
(Root Boy) Jim Cottrell <r...@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
arn...@emory.uucp
>In article <26...@ulysses.homer.nj.att.com> d...@ulysses.homer.nj.att.com (David Korn[eww]) writes:
>>I recently added symbolic links to my version of System V Release 3
>>kernel. I made sure that .. was always handled like an operator that
>>moves you up one level.
>
>The BRL SVR2 Bourne shell can be configured to handle symbolic links
>either way insofar as "cd" and "pwd" go. I always build it to act
>the way the Korn shell does, so that "cd .." never drops me into a
>surprising place.
This can actually be a run time decision instead of compile time; the
shell diffs I posted two years ago from "gatech" did it that way.
>To really address this problem fully satisfactorily, however, one
>does need to make the kernel keep track of the path used to reach
>the current working directory, as well as have ".." handled specially.
The kernel need only keep track of the next to last component of the
pathname used to get into the current directory, not the whole path
name. This would allow ".." to work, although it could admittedly
cause /bin/pwd to give suprising results in some cases. In fact, I don't
see how the kernel's keeping the full path would help with /bin/pwd.
>I think you (David Korn) got it exactly right. Symbolic links are
>useful (thanks, Dennis!), but the deviation from strict hierarchical
>directory structure was a major problem with them. A system with
>a sensible notion of current working directory such as you appear to
>have would be best. Please send the work to the Summit folks so we
>can get good symlink support into SVRn (n > 3.1).
Amen. To change the subject slightly; it has always struck me as wierd
that the mode bits on a symbolic link have absolutely no relevance to
anything; if a symlink is created with mode 000, you can still do
a readlink on it! The problem is, I can't come up with decent semantics
for the mode bits. (I.E. I think the current semantics are wrong, but
I can't come up with anything better.) How does the Ninth Edition
handle it? Comments, anyone?
--
Arnold Robbins
CSNET: arnold@emory BITNET: arnold@emoryu1
ARPA: arnold%emory...@csnet-relay.arpa
UUCP: { akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold
ekr...@hector.uucp
>I think the key word here is "the". The kernel implements symbolic
>links as you describe below; the csh maintains $cwd symbolicly. If you
>do `cd /foo/bar' where /foo/bar -> /whiz/bang followed by `cd ..',
>$cwd gives /foo while pwd gives /whiz. Thus csh is interpreting `..'
>to mean `back' while the kernel takes it to mean `up'.
So the question is: where should you end up?. Ignore for a moment
the problem of where this special treatment of ".." belongs (shell, kernel,
etc). The question is: if a user does a "cd /foo/bar" and then "cd ..",
is it reasonable to expect to be in /foo whether /foo/bar is a symbolic link
or not?.
>In fact, symbolic links are no worse than when root makes links
>between directories. The possibility exists for loops
The kernel will detect a loop with symbolic links when the count of
symbolic links being encountered by namei() while translating a filename
exceeds some constant (8, I think).
>
> What would be the best semantics for ..?
>
>Exactly what they are now as far as the kernel is concerned.
The problem ("cd /foo/bar; cd ..") still remains, then. You could argue that
the special treatment for ".." belongs in the shell, but then what about
a program that does a chdir or the C preprocessor searching for "../x.h" ?
We would really have to change all the programs that deal with filenames
and put special code in them to deal with "..". This is clearly wrong.
>what happens when you type `cd ..', I can see several alternatives.
>Possibly the best is to not treat it specially.
Why?. A user that does "cd /foo/bar" and then "cd .." expects to be in /foo.
He/she doesn't know and DOESN'T NEED to know that /foo/bar is a symbolic link.
Naive users don't even know what symbolic links are.
>consider the case of loops, where after `descending' into the same
>directorys a few times and realizing what happened, do you want to
>retrace your steps in reverse, or go straight up as fast as possible.
Let the kernel deal with the loops. As I said before, after a number of
symbolic links are encounteres, it gives up with an ELOOP error.
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrell
Dave Lennert
path rather than the "hard link" path is that, if you cd to a directory
via a symbolic link and then proceed to compile some C source which does
a #include "../foo/bar.h", then you may not find the same (or any) include
file.
Similar problems arise with tags files.
Such a context sensitive interpretation of ".." would make it impossible
to reliably setup such things.
Symbolic links are mainly a facility to get around certain unix limitations
such as: you can only mount a file system at one mount point at a time (and
hence all the disk space has to be used in one file subtree). It allows
programs with hardcoded pathnames to traverse (one-way) and get to files
even when the sysops need to place the files elsewhere.
I applaud what you're trying to do, though.
-Dave Lennert HP ihnp4!hplabs!hpda!davel
Snipe Hunter
passing through a symbolic link when cd'ing, and finding myself in a totally
different place, but on my personal annoyance scale it doesn't rank nearly
as high as, say, the backwards arguments to strcpy.
Treating ".." as an operator in the shell's cd command does sound like a
nice idea, though. I assume you would have some sort of a stack of
directory names and use that to handle "..". As long as it doesn't create
a directory-depth limitation, fine. You might want to consider making it
an option, turned on and off by setting a variable or something. I would
also like to see an option to have the shell issue a warning message
whenever you pass through a symlink.
I'm not so sure I feel comfortable with treating ".." specially in the
kernel, though. The reason is that, if you do that, then if you have
a symlink which contains ".." in its resolution path, the place that ".."
refers to can be different depending on how you got there. Here's an
example: you have a directory "/foo" which contains a file "f.c". This
file is a symbolic link that points to "../bar/f.c". Now, if you cd
into "/foo" without passing through a symlink, there is no problem with
"f.c"; if you more it, you get the contents of "/bar/f.c". However,
now suppose you have another directory "/xyzzy" with a symlink "plugh"
which points to "/foo". If I understand your proposal correctly, if you
cd to "/xyzzy" and then to "plugh", getcwd will report that your current
directory is "/xyzzy/plugh", not "/foo". The problem comes when you try
to access "f.c"; the symlink will refer not to "/bar/f.c", but to
"/xyzzy/bar/f.c", which doesn't exist.
Does this make sense, or have I misunderstood you completely?
---
"Country beats the hell out of me" -- Jerry Dale McFadden
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
[Ignore header, mail to these addresses]
UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt
or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
ARPA: dcor...@gswd-vms.arpa
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."
h...@beta.uucp
>
> I'm not so sure I feel comfortable with treating ".." specially in the
> kernel, though. The reason is that, if you do that, then if you have
> a symlink which contains ".." in its resolution path, the place that ".."
> refers to can be different depending on how you got there. Here's an
I agree -- but, on the other hand, it *would* sometimes be nice to be
about to treat ".." as the "back" operator (I assume "back" means
follow the path I took to get there, whereas "up" means go up one
level from where I am now regardless of how I got there?) So why
not create another operator -- ",,"? (Or call it whatever you like.)
You could define ".." to be the "back" operator, while ",," is "up".
That way, users who don't know about symlinks can use ".." naively,
and users who are worried about links to things like ../include/f.h
can use ,,. You get a choice.
> Does this make sense, or have I misunderstood you completely?
>
> Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
> [Ignore header, mail to these addresses]
> UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt
> or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
> ARPA: dcor...@gswd-vms.arpa
Makes sense to me -- but I'll always take the system which lets me
choose (that's why I use Unix, where I can choose between shells
and windowing systems, instead of staying on a Mac or something).
..
...Akkana Center for Nonlinear Studies, LANL
akkana%cn...@lanl.gov h...@lanl.gov ihnp4!lanl!hp
"I think I'll take a walk. Hmm, wonder where this wire goes?"
-- Max Headroom
ekr...@hector.uucp
>The kernel need only keep track of the next to last component of the
>pathname used to get into the current directory, not the whole path
>name. This would allow ".." to work,
But "../.." will not. You do need the entire path name if you want to
do it right all the way.
>although it could admittedly
>cause /bin/pwd to give suprising results in some cases. In fact, I don't
>see how the kernel's keeping the full path would help with /bin/pwd.
It won't. What you do then is you make pwd a shell-builtin (like in ksh),
that just echoes $PWD or $cwd or whatever.
John Macdonald
1 >One problem with making ".." an operator and retrace the symbolic link
1 >path rather than the "hard link" path is that, if you cd to a directory
1 >via a symbolic link and then proceed to compile some C source which does
1 >a #include "../foo/bar.h", then you may not find the same (or any) include
1 >file.
>
>Similar problems arise with tags files.
>
>Such a context sensitive interpretation of ".." would make it impossible
>to reliably setup such things.
>
2 >such as: you can only mount a file system at one mount point at a time (and
2 >hence all the disk space has to be used in one file subtree). It allows
2 >programs with hardcoded pathnames to traverse (one-way) and get to files
2 >even when the sysops need to place the files elsewhere.
>
>I applaud what you're trying to do, though.
>
>-Dave Lennert HP ihnp4!hplabs!hpda!davel
I started to use paragraph 1 above as the basis of this followup. In
the process of writing my comments, my thoughts changed so that I strongly
support paragraph 2 above instead.
I was intending to say that there are times when you want ".." to be a
reference to the hard parent, and times when you want a reference to
the soft parent, but that for a given soft link, you usually want the
same parent for ALL references relative to it. Thus if an extension
to soft links was made whereby at the time of creating the soft link
you also specified whether it was a soft-parent-.. or a hard-parent-..
form of soft link and then the kernel would arrange either one for you.
However, I then thought that once you have set up and used both of these
forms for their appropriate purposes, then it would start to seem quite
reasonable to want both parents available. (e.g. you run make in a
soft-linked directory - you want <#include "../h/foo.h"> to go to the
hard ../h, but you want <cc .... ../lib ....> to go through the soft
link to your newly written version of the library - the one that you
are trying to test.) This leads to wanting more versions of soft-links:
"search order is: soft link only for write, soft link first and hard link
second for read" and its 5000 nearly identical brethren.
The concept of the soft link is a wart on the Unix file system. It
is elegant, powerful, and valuable, but a wart none the less. It
contravenes the important principle that ". and .. are the only
circular links". This principle is an implicit assumption of much of
the software on Unix systems and of most of the users. It is often
used in ported source code (#include "../h/foo.h" as mentioned above).
Thus, I am lead to the conclusion that soft-links to directories should
be avoided in places where .. is going to be used. It is too likely
to cause problems that are hard to notice and diagnose. (I can imagine
an entry in the risks forum about a system that was released after
successfully passing a complete test suite, except that because of an
forgotten soft link, the test suite was linked and run using the old
proven production library instead of the new freshly compiled library
that was supposed to be getting tested.)
The only system that I have access to that provides soft links specifies
that soft links to a directory may only be done by the super-user. It
would appear that other people have come to the same conclusion. (I
presume that this is a standard restriction on all systems with soft
links. If not, then perhaps it should be.)
--
--------- .signature eater food ---------
John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
internet:Sorry. We're in range, but we're in no domain.
Disc-claimer: (noun) any hack's source directory
j...@rtech.uucp
per se that are a botch, it's allowing links (symbolic or not)
to directories. As soon as you do that, the file name space changes
from a tree to a dag, so there is no longer a unique path "up" to
the root (i.e., ".." becomes ambiguous). Regardless who keeps track
of the path you took to a particular node -- shell or kernel -- ".."
may not mean what you want it to mean (didn't somebody mention "../path"
in "#include" directives?)
--
Jim Shankland
..!ihnp4!cpsc6a!\
rtech!jas
..!ucbvax!mtxinu!/
c...@lrt20.uucp
I consider to be one of the biggest uses of symbolic links. I have a directory
full of symbolic links pointing at various useful places around a quite
complex tree, these symbolic links are named as mnemonics for the various
places they point at and the directory containing them is included in my
CDPATH. I then can say "cd <mnemonic for somewhere close>/../<where I really
want to be>" without having to type in lengthy pathnames.
Chris Seabrook
MAIL: c...@root.co.uk
SNAIL: Root Computers, Saunderson House, Hayne Street, London EC1A 9HH
PHONE: +44 1 606 7799
Andy Valencia
>As soon as you do that, the file name space changes
>from a tree to a dag
Actually, it can have cycles (see ELOOP), so it's even
worse than you thought! But until I can think up something more
satisfying, I'm not going to take pot shots at it. After all, it
sure has come in handy on occasion.
Andrew Valencia
van...@lindy.stanford.edu
br....@rlg.BITNET
William E. Davidsen Jr
I sent a *much* longer version of this to David Korn directly, but I
thought I would post a summary of my thoughts to the net. I have my
flame suit on.
Problems:
a) permissions - ignore, new meaning, ?
b) loops?
c) links to files, directories?
d) links to FIFOs (this is SysV)
Possible area(s) of better solution:
Could a special form of the mount call be used to mount one
subdirectory in another? UNIX really knows how to handle mounts, so it
shouldn't unduely confuse applications and backups.
Would this effect the .. problem, for better or worse?
--
bill davidsen (we...@ge-crd.arpa)
{chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
Snoopy
>per se that are a botch, it's allowing links (symbolic or not)
>to directories.
But, *not* allowing symlinks to directories would be a botch!
Everyone repeat after me:
"Everything is a file."
Symlinks to directories (like RCS directories on remote machines)
are extremely useful. Symlinks to 'special' files (like tape drives
on remote machines) are very useful. I almost never make symlinks to
'regular' files.
Yes, the "cd .." and "pwd" stuff can get a bit confusing when you're
lost in a twisty mazy of symbolic links, all different. How about
adding options to cd and pwd (and whatever) to specify going up rather
than back? [yeah, I know, Yet Another Option :-( ] Sometimes it would
be handy to get pwd to tell you both paths.
As far as permissions of symlinks go, it would be nice to be able to
change them so that they can be made to blend in and not show up
when doing, say, a "find -perm". Even if they continue to not
mean anything.
Snoopy
tektronix!doghouse.gwd!snoopy
sno...@doghouse.gwd.tek.com
Eduardo Krell
>Problems:
> a) permissions - ignore, new meaning, ?
> b) loops?
> c) links to files, directories?
> d) links to FIFOs (this is SysV)
I don't see how these things are related to the treatment of ".." in a different
way. If this are general arguments against adding symbolic links to System V,
then the answers are:
a) You need read permission on the symbolic link itself and then whatever
permissions you require are matched against the file/directory/whatever
the link is pointing to.
b) The kernel as a built-in limit on the number of symbolic links it can
expand while translating a given pathname. This handles loops.
c) Yes, yes.
d) Why not?. A Symbolic link is an abstraction that can point to anything.
The idea is to extend the hard link mechanism to allow for links to
cross file system boundaries.
gw...@brl-smoke.uucp
but doesn't take sole credit for the idea, which came up in a group
discussion at Berkeley. He also doesn't much like Korn's idea of "..",
on the grounds that it adds structural complexity. My counter-argument
is that the strict directory hierarchy is such an important idea that it
should take precedence when there are conflicting possibilities; for
example, an RFS server will pass back evaluation of a pathname to the
client when a ".." path component crosses over a remote-mount point.
(So there is precedent for Korn's handling of "..".)
I hope I haven't misrepresented what Dennis told me last week.
gw...@brl-smoke.uucp
>is that the strict directory hierarchy is such an important idea that it ...
Upon re-reading my previous posting, I noticed that I didn't make clear what
to me is the telling point: The Korn handling of ".." makes the file system
appear at least LOCALLY hierarchical, even though GLOBALLY it's not. Since
".." normally has use only for such local behavior, Korn's approach seems
appropriate for it.
The argument someone supplied about the contents of a symlink being "../foo"
doesn't seem relevant if the "../foo" is interpreted relative to the actual
current directory containing the symlink; the pathname involved in the open()
(or stat() or whatever) should not be affected by the contents of any symlinks
encountered along the way. Proper local handling of .. within a symlink is
thus different from proper handling of .. in the user pathname context.
eic...@bloom-beacon.uucp
>...
>I consider to be one of the biggest uses of symbolic links. I have a directory
>full of symbolic links pointing at various useful places around a quite
>complex tree, these symbolic links are named as mnemonics for the various
>places they point at and the directory containing them is included in my
>CDPATH. I then can say "cd <mnemonic for somewhere close>/../<where I really
>want to be>" without having to type in lengthy pathnames.
is that it refuses to resolve .. as the parent of the directory at the
other end of this symlink, but rather as the previous component of the
name. If I wanted to come back up the name, I would just type
"Meta-DEL" in the filename window, and be back at the top of the link.
This way I would have a clear choice of which type of parent I want.
Unfortunately, it is not implemented that way; no one in comp.emacs
has suggested patches, and I don't have time to fix it myself.
/Happy Hacking........\\.............Mark Eichin/
<eic...@ATHENA.MIT.EDU><SIPB member & Watchmaker>
j...@rtech.uucp
>In article <8...@rtech.UUCP> j...@rtech.UUCP (Jim Shankland) writes:
>>Minor point relating to this discussion: it's not symbolic links
>>per se that are a botch, it's allowing links (symbolic or not)
>>to directories.
>
>But, *not* allowing symlinks to directories would be a botch!
>Everyone repeat after me:
>
> "Everything is a file."
that is at issue; all the complaints about symbolic links (whether or
not they are justified) are really complaints about links to
directories.
Repeating that everything is a file, whether or not it is true, is not
a useful exercise. A terminal is a file, but I can't seek on it;
a (vanilla) pipe is a file, but I can neither seek on it nor name it;
/etc/passwd is a file, but I can't mount it; the swap partition is a file,
but I can't put it into cbreak mode; and so on.
>
>Symlinks to directories [examples omitted] ... are extremely useful....
>
>Yes, the "cd .." and "pwd" stuff can get a bit confusing.... How about
>adding options to cd and pwd (and whatever) to specify going up rather
>than back? [yeah, I know, Yet Another Option :-( ] Sometimes it would
>be handy to get pwd to tell you both paths.
In general, having turned the name space into a dag (graphs with cycles,
not being well-formed name spaces, are not considered), there may be more
than two ways "up;" "pwd" could output arbitrarily many paths. Sure,
links to directories are useful; but they also lead into a semantic swamp.
I'm not advocating a particular solution (don't have one); just trying
to clarify the problem.
g...@gorodish.uucp
thing, it's difficult, if not impossible, to forbid:
$ >foo # create plain file
$ ln -s foo bar # make "bar" a symlink to "foo"
$ rm foo; mkdir foo # now "bar" is a symlink to a directory
or
$ ln -s foo bar # make "bar" a symlink to a nonexistent file
$ mkdir foo
Disallowing symbolic links to nonexistent files - or, in fact, doing
ANY checking of the contents of the symbolic link - would tick off a
lot of people. For example, I think the ISIS user-level distributed
file system library supports symbolic links to remote files; the
syntax for remote files is some sort of "host:pathname" syntax.
Symbolic links to directories may be a pain, but it's a pain we'll
have to live with unless we forbid symbolic links completely.
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com
Robert C. White Jr.
I have been reading these articles since I joined USENET [some 1.5 weeks
ago] I feel that I am fairly well informed but...
What is a "symbolic" link?
Is is different from a regular link?
am I crazy? :-)
Did I miss something important in my education? 8-)
Someone please respond or mail me an explination.
Thanks.
Robert.
John Haugh
stop reading now if you want to.
I spent some time using Ultrix on a uVax-II and sort of liked it. The
biggest problem I had was understanding what I got if I stat(2)ed a symbolic
link. My USG-Unix brain says I should get a stat structure saying I found
a symbolic link. But I don't seem to believe this is the way it works.
Please, send some manual pages to this poor degenerate System V user. I need
the confusion at this time in my life.
- John. (j...@killer.UUCP) (Down and out in the Big D)
Disclaimer:
No disclaimer. Whatcha gonna do, sue me?
g...@gorodish.uucp
It is a special kind of "file". The "contents" of the file are a
string representing a pathname; most references to the file are
converted by the system into references to the file specified by that
pathname.
> Is is different from a regular link?
Yes. A regular link, in effect, is a map between a file name and a
particular inode on the file system where the directory containing
that link resides; a symbolic link is a map between a file name and
whatever file happens to have another file name.
For one thing, this means that symbolic links can be made to files on
other file systems. For another, if you have two hard links to a
file, and do an "mv" to replace one of those links with a link to a
different inode, the second hard link will still refer to the
original inode, and thus the original file. If you have a symbolic
link to a file, after the "mv" the symbolic link will refer to the
new file.
In addition, you can make symbolic links to directories; only the
super-user can make hard links to directories in most UNIX systems,
and even that is very much NOT recommended. (The main reason it's
supported at all is that in many UNIX systems, the only way to rename
a file is to make a second hard link to it with the new name, and get
rid of the hard link with the old name.)
> Did I miss something important in my education? 8-)
Well, the more you know about various UNIX implementations, the
better; for one thing, it means you can sometimes avoid reinventing
the wheel (or, worse, the *square* wheel).
Root Boy Jim
In article <77...@brl-adm.ARPA> r...@icst-cmr.arpa writes:
>I think the key word here is "the". The kernel implements symbolic
>links as you describe below; the csh maintains $cwd symbolicly. If you
>do `cd /foo/bar' where /foo/bar -> /whiz/bang followed by `cd ..',
>$cwd gives /foo while pwd gives /whiz. Thus csh is interpreting `..'
>to mean `back' while the kernel takes it to mean `up'.
So the question is: where should you end up?. Ignore for a moment
the problem of where this special treatment of ".." belongs (shell, kernel,
etc). The question is: if a user does a "cd /foo/bar" and then "cd ..",
is it reasonable to expect to be in /foo whether /foo/bar is a symbolic link
or not?.
Yes, it is reasonable. Is it the best thing to do? Maybe. If you write
a shell that does this, I won't barf. It would be nice if the behavior
was controlled by a switch (some have done this). One could even use
the notation `...' to mean "*rindex(cwd,'/') = 0;". Strrchr for TPC folks.
>In fact, symbolic links are no worse than when root makes links
>between directories. The possibility exists for loops
The kernel will detect a loop with symbolic links when the count of
symbolic links being encountered by namei() while translating a filename
exceeds some constant (8, I think).
I know that, and it's irrelevant. But it won't detect hard link loops,
except by length of pathname limits. One of my points was this:
cd /usr; mkdir a; mkdir b;
ln -s /usr/a b/a; ln -s /usr/b a/b
cd a; cd b; cd a
cd ..; cd ..; cd ..
In a case like this, the shell would have no problem, but the kernel
would have to remember the entire history of how you got here. After
line 3 csh would think we were in /usr/a/b/a, which is really /usr/a.
The first exit out of a takes us to /usr/b, but the second takes us
to /usr.
> What would be the best semantics for ..?
>
>Exactly what they are now as far as the kernel is concerned.
The kernel has no history of pathnames. Your working
directory is inode 347.
In fact, maybe it should. Allow me to restate Korn's proposition as
"THE IDEA OF A DISEMBODIED `WORKING DIRECTORY' IS A BOTCH"
Why not just go all the way? Keep *both* pieces of info in the inode
in core: where we are (inode 347), and how we got here. Keep the
same semantics for `..' since our graphs will still look pretty much
like trees, and make `...' be `where you came from'. Obviously,
... cannot be kept on disk, and the kernel would have to implement
the semantics of `...'. Right now, it doesn't know about `.' and `..'.
Symbolic links would *not* be resolved in the inode structure.
The problem ("cd /foo/bar; cd ..") still remains, then. You could argue that
the special treatment for ".." belongs in the shell, but then what about
a program that does a chdir or the C preprocessor searching for "../x.h" ?
We would really have to change all the programs that deal with filenames
and put special code in them to deal with "..". This is clearly wrong.
One should be careful when using links, hard or soft. I would add, however,
that bombing out when `../x.h' cannot be found is better than finding
another x.h in another directory. "Hey Ralph, I can't compile this!"
"Yeah? Did you cd thru a symbolic link to the source directory?"
"Yeah, I've been cd'ing all over the place. I better login again."
This is clearly even worse. Use `#include ".../x.h"'.
On second thought, DON'T! Or the anecdote I described becomes a nightmare!
>what happens when you type `cd ..', I can see several alternatives.
>Possibly the best is to not treat it specially.
Why?. A user that does "cd /foo/bar" and then "cd .." expects to be
in /foo. He/she doesn't know and DOESN'T NEED to know that
/foo/bar is a symbolic link. Naive users don't even know what
symbolic links are.
Those last two statements contradict each other. It would be nice if
one didn't have to know about symbolic links. However, if /foo/bar
points to /qaz/wsx, then he needs to know!
Besides, no one can remember what directory they're in anyway. That's
why we have the pwd command, or have $cwd as part of our prompt. And
the latter fails across symbolic links.
>consider the case of loops, where after `descending' into the same
>directorys a few times and realizing what happened, do you want to
>retrace your steps in reverse, or go straight up as fast as possible.
That is not me being quoted. I think it's Korn. The answer is, possibly
either. So gimme both `..' and `...' please.
Let the kernel deal with the loops. As I said before, after a number of
symbolic links are encounteres, it gives up with an ELOOP error.
Well, loops are pretty pathological in either case. Even without loops,
the same problems exist.
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrell
(Root Boy) Jim Cottrell <r...@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
Hello. Just walk along and try NOT to think about your
INTESTINES being almost FORTY YARDS LONG!!
t...@ism780c.uucp
< It would be like Version 6, right? I think `cd ..' didn't work at
< the `root' of a mounted file system.
Correct, it didn't.
On System V before release 3, and on TS 1.0 ( and, I suspect, on
all other AT&T Unix systems ), the kernel did not actually check
for "..". Instead, it checked for inode == 2 and the second
character of the name being "." and the file being a directory.
This allowed some interesting things:
# umount /dev/dsk/usr.disk
# mkdir /usr/a.dir
# mount /dev/dsk/usr.disk /usr
# cd /usr
# ln .. a.dir
Now, if you do "cd .." from /usr, you end up in /, but if you
do "cd a.dir" ( which is a link to ".." ) from /usr, you end
up in the a.dir directory under /usr on the root file system.
--
Tim Smith "Well if you want to say yes, say yes
{seismo,sdcrdcf}!ism780c!tim And if you want to say no, say no
'Cause there's a million ways to go
You know that there are"
Root Boy Jim
>Symbolic links are mainly a facility to get around certain unix limitations
>-Dave Lennert HP ihnp4!hplabs!hpda!davel
This leads to wanting more versions of soft-links:
"search order is: soft link only for write, soft link first and hard link
second for read" and its 5000 nearly identical brethren.
Hey, neat! Let's go to 32 bits for modes! Other rwxrwxrwx values :-)
would mean `symbolic write link for owner', `symbolic read link :-)
for group', `symbolic execute (or search) link for others', etc. :-)
The extra sticky bit would determine whether `..' was `up' or back' :-)
The concept of the soft link is a wart on the Unix file system. It
is elegant, powerful, and valuable, but a wart none the less. It
contravenes the important principle that ". and .. are the only
circular links". This principle is an implicit assumption of much of
the software on Unix systems and of most of the users. It is often
used in ported source code (#include "../h/foo.h" as mentioned above).
So is the concept of a hard link. "What, how come my file changed?"
"Well, it's a link to this *other* file, and I changed *that* one, and ..."
So is the concept of a mounted file system, for that limits hard links.
Thus, I am lead to the conclusion that soft-links to directories should
be avoided in places where .. is going to be used. It is too likely
to cause problems that are hard to notice and diagnose.
Caution is advised.
The only system that I have access to that provides soft links specifies
that soft links to a directory may only be done by the super-user.
Too cautious.
It would appear that other people have come to the same conclusion. (I
presume that this is a standard restriction on all systems with soft
links. If not, then perhaps it should be.)
It is not. I will agree that there are some semantic areas of symlinks
that have not been fully addressed. I would like to see an extensive
paper written on all the options and choices made regarding symlinks.
Some of these seem to be made on an ad hoc basis. Some programs know
about them, some don't. What decisions were made and why?
--------- .signature eater food ---------
John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
internet:Sorry. We're in range, but we're in no domain.
Disc-claimer: (noun) any hack's source directory
Snoopy
>> "Everything is a file."
>Repeating that everything is a file, whether or not it is true, is not
>a useful exercise. A terminal is a file, but I can't seek on it;
>a (vanilla) pipe is a file, but I can neither seek on it nor name it;
>/etc/passwd is a file, but I can't mount it; the swap partition is a file,
>but I can't put it into cbreak mode; and so on.
There is a difference between saying "You can't because it is impossible"
and saying "You can't because I won't let you." One of the big wins in
Unix is that it doesn't put up artificial restrictions.
>>Yes, the "cd .." and "pwd" stuff can get a bit confusing.... How about
>>adding options to cd and pwd (and whatever) to specify going up rather
>>than back? [yeah, I know, Yet Another Option :-( ] Sometimes it would
>>be handy to get pwd to tell you both paths.
>In general, having turned the name space into a dag (graphs with cycles,
>not being well-formed name spaces, are not considered), there may be more
>than two ways "up;" "pwd" could output arbitrarily many paths.
I'm think of having the shell remember how you got somewhere, and having
a built-in pwd tell you how you got there (using the symlink names),
while "pwd -L" (or "/bin/pwd" ?) would give the "real" path. There
could be many possible paths through symbolic links to get there,
but you only got there one way, so there is only one symbolic link
path to print out.
Guy Harris writes:
| Disallowing symbolic links to nonexistent files - or, in fact, doing
| ANY checking of the contents of the symbolic link - would tick off a
| lot of people. For example, I think the ISIS user-level distributed
| file system library supports symbolic links to remote files; the
| syntax for remote files is some sort of "host:pathname" syntax.
I don't know about ISIS, but with DFS I can say
ln -s //machine/usr/foo/src/bar/RCS RCS
make bar
and *presto*, everything works. Very nice!
| Symbolic links to directories may be a pain, but it's a pain we'll
| have to live with unless we forbid symbolic links completely.
Or until we figure out how to deal with them properly. A surprising
number of utilities need to know about the existance of symlinks.
A lot of the problems with symlinks is that various utilities don't
support them properly. For example, what does your ls do when you
say "ls -lFL" for a symlink pointing at non-existant file? Mine does:
?????????? ? ???????? ? ??? ? ??:?? foo <- bar@?
What else can it do? The info it wants to print isn't there.
Chris Torek writes: (from the /dev/stdin discussion)
} One of the wonderful things about Unix is its simple naming scheme.
} Everything is a file. Want to see a file? `cat foo'. Want to
} see a directory? `cat .'. Want to see what is on a tape? `cat
} /dev/tape/rdefault' [*]. In V8 processes became files, through
} /proc. This is the right way to go.
Hey, does this mean I could have a symlink to a process??
(If I had v8) Cosmic!
Snoopy Unnecessary restrictions?
tektronix!doghouse.gwd!snoopy Just say NO!
sno...@doghouse.gwd.tek.com
David Zink
What's the difference between :
mkdir foo
ln -s `pwd` foo/foo
followed by reference to a pathname with infinite foo/'s in it as compared
with a pathname with infinite ../'s in it?
What's the point of outlawing some loops and not others? And what's more
important, why invalidate otherwise valid pathnames?
I'm serious, Isn't the maximum pathname length a firm enough limit on looping?
ELOOP is just a lie, after all, based on a stupid assumption.
Symbolic links have to break code with ..'s in it because half will mean up
and half will mean back; why change the meaning of .. to break one half
when we can just leave the meaning the same and still break half.
(or is it just the ATT crowd saying lets do the ATT botch that's not like the
UCB botch?)
David Zink.
k...@munnari.uucp
> What's wrong about more than eight symbolic loops?
There's nothing magis about 8, pick any number you like, (it should
probably be a config parameter), however there has to be a limit.
> Isn't the maximum pathname length a firm enough limit on looping?
No, symbolic links aren't expanded into the pathname, to make a long
string that is then looked up normally.
Rather, the contents of the symlink simply replace the component that
is the name of the symlink.
So, consider
ln -s a a
then open("a", 0);
if there was no limit, the kernel would iterate on the symlink
forever, as the name length is continually 1, after every time
he symlink replaces the component.
Of course, the kernel could trivially catch this degenerate case,
but expecting it to catch
ln -s a z
ln -s b a
ln -s c b
...
ln -s z y
is expecting a little too much.
On the general question of symbolic links .. I have changed my
opinion on them recently, not their usefulness, but on how they
should be seen to the user. I used to believe that a symlink
should appear as a link in as many ways possible (so much that
I have always changed the sense of the 'L' flag in "ls" so that
the default is to show the file linked to, rather that the symlink
itself).
However, I'm not of the opinion that this is wrong. Symlinks
should be regarded as real objects, and not as poor cousins.
I'm no longer going to fool with "ls".
Most of the "problems" with symlinks seem to be because we seem
to want to forget that symlinks exists, and just pretend that they
are directories (to the extent of having ".." reverse a symlink,
a totally absurd idea).
Much better would be to simply educate users, let them see symlinks
as real objects in the filesystem. At the minute, I have to know
that 'foo' is a directory before I attempt "cd foo", I'm expected
to remember that (or discover it). Expecting users to know that
'foo' can be either a directory or a symlink, and that which it
is causes different effects, isn't too much to ask I think.
Its time for symlinks to come out of the closet. Stand up and be counted!
This does mean implementing sensible semantics for most of the sys
calls when applied to symlinks, chmod should work (rather than passing
through), and the modes should mean things. "r" would let you see
the contents of the symlink, "w" allow you to change it, and "x" to
access its value in a path lookup. I have ideas for the set[ug]id
bits, and I'm sure a meaning for sticky will come to me! I would like
to discard "readlink" and replace it with "read", probably with an
extra mode to open to say "don't follow". Then "write" could be used
to change the value of a symlink ("symlink" could be replaced by
"mknod, write" but I think that's going a bit far). Rename, unlink,
and chown already work properly. stat and lstat are OK. Access is
a tricky one, an extra "don't follow" mode bit is probably needed there.
"Link" is hard, both meanings make sense, and there's no flags word
with convenient unused bits in it. This might necessitate a new syscall
(ala stat/lstat which was in the same position). The sys calls that take
a path for some odd purpose (acct, mount, etc) should just operate as they
do now.
kre
mk...@teknowledge-vaxc.uucp
(with regard to mode bits on a symbolic link)
>access its value in a path lookup. I have ideas for the set[ug]id
>bits, and I'm sure a meaning for sticky will come to me! I would like
OK, so what meanings attach to set[ug]id and sticky bits when applied
to the mode of a directory or the mode of a device file?
Mike Khaw
--
internet: mk...@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
ekr...@hector.uucp
>I'm So confused. What's wrong about more than eight symbolic loops?
>What's the difference between :
>mkdir foo
>ln -s `pwd` foo/foo
>followed by reference to a pathname with infinite foo/'s in it as compared
>with a pathname with infinite ../'s in it?
How can you have an infinite number of ".."s in a filename unless you
encounter a loop somewhere (either symbolic or hard link)?.
>What's the point of outlawing some loops and not others? And what's more
>important, why invalidate otherwise valid pathnames?
All loops are invalidated (ie, catched). Someone decided that 8 was large
enough for the maximum number of symbolic links encountered during the expansion
of a particular pathname.
>(or is it just the ATT crowd saying lets do the ATT botch that's not like the
>UCB botch?)
It isn't an ATT vs BSD battle. The point is that some people considered
the semantics of symbolic links as implemented in BSD to be a botch. If
symbolic links could be added to System V, should they be broken too
(just to keep BSD compatibility), or should they be done the right way?
Jonathan Clark
Listen guys, if I say 'cd a/b/c/d/e;cd ..' then I am now in a/b/c/d,
regardless of how many symlinks or networked file systems I had to go
through to get there. Anything else is brain-damaged.
On a similar note, for the people who are expounding starting one's
shell scripts with "#! /bin/csh", the logical continuation of this is
to start one's C programs with "#! /bin/cc", and so on. Writing a
language processor which is a partial superset of an existing standard
is one thing, and quite OK in my book; hacking the kernel to support this
automagically is quite another. Perhaps csh should have been made to
interpret a strict superset of the Bourne shell, so that normal scripts
work under it, and then csh scripts should have been interpreted via
"csh script"? Then we wouldn't have this problem.
--
Jonathan Clark
[NAC,attmail]!mtune!jhc
An Englishman never enjoys himself except for some noble purpose.
Milan Moncilovich
> To change the subject slightly; it has always struck me as wierd
> that the mode bits on a symbolic link have absolutely no relevance to
> anything; if a symlink is created with mode 000, you can still do
> a readlink on it! The problem is, I can't come up with decent semantics
> for the mode bits. (I.E. I think the current semantics are wrong, but
> I can't come up with anything better.) How does the Ninth Edition
> handle it? Comments, anyone?
In article <17...@munnari.oz> k...@munnari.oz (Robert Elz) writes:
>This does mean implementing sensible semantics for most of the sys
>calls when applied to symlinks, chmod should work (rather than passing
>through), and the modes should mean things. "r" would let you see
>the contents of the symlink, "w" allow you to change it, and "x" to
>access its value in a path lookup.
Can someone explain why symlinks were set up this way (modes ignored)?
It's always been a hassle for me, and I don't see much benefit from the
behavior.
Fr'instance, I like to do a "chmod 311" on my binaries so that, when I do
grep blat *
in a directory full of shell scripts and binaries, "grep" won't print
garbage when it finds a match for "blat" in the middle of a binary file.
If I have a symlink pointing to a binary, and the binary doesn't belong
to me, a "chmod 311" on the symlink complains "chmod: <link-name>: Not owner".
Why were symlinks set up this way, and why shouldn't they be fixed as
Robert Elz suggests?
--Jerry Peek
uucp-style: {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp
Domain-style: jer...@tektools.TEK.COM
I don't speak for Tektronix or its employees (or even for myself, at 6 AM).
Lyndon Nerenberg
> to the mode of a directory or the mode of a device file?
One system I maintained (running a Unisoft port) used the sticky bit
on a 777 directory to mean "anyone can create a file here, but only
the owner can delete it". This was used on /tmp and /usr/tmp.
This would be useful in a number of situations. On our MiniFrame,
/usr/spool/uucp must be 777 in order for cu(1) to create and
unlink the lock files for the port, despite the fact that the
damn thing runs suid to root :-( Therefore, it is possible for
anyone to bounce in and type "rm -f" ... Having the sticky bit
mod available for this directory would go a long ways towards
fixing this rather blatent hole.
Guy Harris
> regardless of how many symlinks or networked file systems I had to go
> through to get there. Anything else is brain-damaged.
Which can, in most cases, be done by the shell interpreting the "cd"
command; the question is whether one should add extra stuff to the
kernel to make this work invisibly? I tend to agree with what was
given as Dennis Ritchie's position, which was "no".
> On a similar note, for the people who are expounding starting one's
> shell scripts with "#! /bin/csh", the logical continuation of this is
> to start one's C programs with "#! /bin/cc", and so on.
No. Executable files begin with a magic number, which indicates the
interpreter to be used to execute that file. The "conventional"
magic numbers indicate that the interpreter in question is the
machine's hardware (including microcode if you have it); the "#!"
magic number selects a program to be used as the interpreter. One
would start C programs with "#! /usr/bin/c_interpreter" or something
like that; unless one has a C interpreter, one does not normally
execute C code.
The intent behind "#!" was to permit *arbitrary* interpreters to run
programs, not just shells. (It also permits interpreted programs to
be set-UID, assuming you trust the interpreter's mechanisms to the
degree necessary to make set-UID interpeted programs safe. Prior to
4.3BSD, there were two very large security holes that rendered
set-UID shell scripts, at least, unsafe; those two holes were closed
in 4.3BSD, but there could well be others.)
> Writing a language processor which is a partial superset of an existing
> standard is one thing, and quite OK in my book; hacking the kernel to
> support this automagically is quite another.
Huh? How does "#!" "automagically" support "...a language processor
which is a partial superset of an existing standard"? What it
supports is executing shell scripts as ordinary programs *without*
having to ensure that all programs that might try to execute that
script use "exec[lv]p" instead of "exec[lv]". The latter is somewhat
nice, considering that not all programs *do* use "exec[lv]p".
> Perhaps csh should have been made to interpret a strict superset of the
> Bourne shell,
Considering that the C shell, I believe, antedated the Bourne shell
(or, at least, the public availability of the Bourne shell), this
might not have been practical.
> so that normal scripts work under it, and then csh scripts should have
> been interpreted via "csh script"? Then we wouldn't have this problem.
"#!" was not concocted merely to solve the C shell vs. Bourne shell
problem. I presume DMR came up with it as a nice generalization of
the notion of "executable image" and "magic number"; the cost in
terms of kernel code is small, and the benefits seem to outweigh
them.
Geoff Espin
Sorry to FLAME you but...
1) You posted to comp.unix.wizards which is supposedly for "advanced"
questions [1]. You should at least have had the sense that your
question was of a basic nature, i.e. maybe fit for comp.unix.questions.
You are "fairly well informed" about what? AIDS? Aren't we all by now?
2) The "man" command can be useful. It's actually faster than sending
junk queries over the net -- though the output is rather predictable. :-(
Presuming that you're not on some relic UNIX system without symbolic
links, try: man ln
3) Your spelling is atrocious, especially the following mapped files
discussion. Please run your letters through "spell",
or better still "| head -0" :-)
---
[1] Here's to calling the kettle black, but I couldn't mail to nu3b2?
Geoff
d...@alice.uucp
disturb the near tree shape that convention gives to the Unix file
system. Trees are easily understood both by people and by programs;
more complicated shapes are not. Already, even in the traditional file
system, the existence of shared leaves (hard links) causes a certain
amount of confusion. With symbolic links the situation is considerably
messier because the shape is that of a general graph (not a DAG). For
the most part, the BSD and V8 conventions for dealing with symbolic
links are well-chosen, but there has still been a significant increase
in complexity; this is indicated, for example, by continual questions
about which operations should follow links, and which should not.
Even if all the questions are given a satisfactory answer, their
existence suggests that something is wrong.
Nevertheless, symbolic links are sometimes useful, mainly because the
attractive and well-controlled tree-shaped file system does not always
map well onto real disks or remote machines. Unix makes it easy to
move a node in the file system tree and its descendants to
a separate disk partition or perhaps to another machine, but not to
put several such nodes into one partition unless their parent and all
their siblings are there as well.
If we are to have symbolic links, I would, therefore, like to make
them as obvious as possible instead of as transparent as possible,
because they cannot be transparent; they introduce a new and not
easily comprehended structure. That is, I would like people to be able
to think of the file system as truly a tree (albeit with readily
understood annotations like `..') and to have any symbolic links
understandable as abbreviations or macros used in naming the actual
structure. Thus it disturbs me not at all that our pwd gives one's
actual location in the tree.
In particular, Korn's proposal to reinterpret the meaning of ..
depending on the history of the process seems unfortunate, because
`..' no longer has any meaning with repect to the hierarchy; indeed,
there no longer is any hierarchy. (Thoughts about `...' seem
only to make matters worse).
Another way to put this is that the proposal promises more than it
can possibly deliver; it does make certain local operations like
`pwd; cd symlink; pwd' behave more as they would if the graph
were a tree, at the cost of concealing the global structure.
The simulation of the tree has further peculiarities: `ls symlink/..'
and `cd symlink; ls ..' still behave differently.
The real problem is the symbolic links themselves, but I think
the proposal exacerbates it rather than relieves it.
Dennis Ritchie
Brian Beattie
In article <26...@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes:
>If symbolic links could be added to System V, should they be broken too
>(just to keep BSD compatibility), or should they be done the right way?
>
> Eduardo Krell AT&T Bell Laboratories, Murray Hill
>
> {ihnp4,seismo,ucbvax}!ulysses!ekrell
Would you care to discuss what is in your view the right way?
Thanx
--
-----------------------------------------------------------------------
Brian Beattie | Phone: (703)749-2365
NetExpress Communications, Inc. | uucp: seismo!sundc!netxcom!beattie
1953 Gallows Road, Suite 300 |
Vienna,VA 22180 |
ekr...@hector.uucp
>Would you care to discuss what is in your view the right way?
In this case, the "right way" would be one where "cd foo; cd .." does
what a naive user expects it to do (which is done by the way at mount
points and remote file system mount points anyway). To be really perfect,
though, it shouldn't break any current code.
These two are conflicting goals and the question is whether we should
leave them broken the way they are (the argument here being compatibility
and such) or try to change their semantics.
I don't know the answer but I certainly like the idea of "cd a/b; cd .."
being equivalent to "cd a" whether "a" is a mount point, RFS mount point
or a symbolic link.
Steve Nuchia
(Isn't is about time we changed the subject line? :-)
In my experince, which is oriented towards software engineering
in general and portable commerical software in particular, links
to directories are about a 70% solution - they are helpful but
aren't _exactly_ the right thing.
Let me describe what I've whished for, and show how it could
be useful in other contexts.
Instead of allowing directories to be links to another directory,
have an object with the superficial semantics of a directory but
implementing a "copy-on-write" window onto a search path of other
directories, perhaps chained to arbitrary depth. I'm not concerned
with implementation directly here; please allow me to speak (?)
a little metaphorically.
As a version control mechanism the application is obvious: each version
is a "copy-on-write" image directory, with files carried through from
previous versions visible but not modifiable. A similar scheme was
described in the Portland usenix proceedings under the title
"A Rich Man's SCCS" or something like that. The author modified
a large number of standard utilites, notably cp and the editor,
to achieve essentially the semantics I describe using standard
hard links.
In environments requiring customized bin direcories, notably
heterogenous NFS nets and "universe" implementations, the standard
practice is to have a directory for each requirement, with each
NFS host symlinking or mounting or whatever the right one. In
universe implementations it is customary to have the symlink
mechanism switch off of the universe flag. The shortcoming in
both cases is that files held in common between the two require
special maintenance (shell scripts? ...). My directories would
simply have the shared stuff in the right place and then different
folks would search for their different strokes by following their
appropriate links. (A similar requirement was brought up not
too long ago in reference to the netnews software: In a NFS
environment the "libdir" need sto be "purified" of binary files;
a perfect application of this concept).
I have occasionally had to build a directory with a link to each
file in another directory and then make a few small changes in
the set of files: a deletion here and an addition there. Situations
come up often where it would be nice to be able to set up a
directory "just like" another "except for ...". Sure, there are
(almost) always workarounds, but you recognize what I'm talking
about, don't you?
Then there's rsh bin directories (Restricted, not Remote SHell),
various reasons for a writable copy of a read-only directory,
etc. In fact, wouldn't it be nice if ~/bin was an image-link
to /bin:/usr/bin? Sure, we've got mechanisms for doing the same
thing, but it would be a cleaner world without execvp(2). :-)
Implementation shouldn't be a huge challenge, and I'd use this
a lot more frequently than links to directories. If I wanted
the other directory I'd just use it: Except for crossing mount
points, symlinks to directories are of precious little use to
me. Image links are a horse of a different color, And I'd like
to hear from those in whom my remarks strike a responsive chord.
The semantics of the proposed facility need to be nailed down,
and an existance proof of implementability need to be sketched.
(needless to say, the implementation scheme will define the
semantics as usual, but we can dream, right? :-)).
Flames to /dev/null: I've thought about this a lot and would like
the courtesy of a well thought out refutation. 1/2*:-)
It is my hope that this will serve as a fulcrum to turn
the discussion away from all the things that _are_ wrong
with links to direcories and towards a better way to do
their job. I could probably do a better job on the presentation
if I didn't try to write this late at night, but its now or never...
Thank you for your attention.
Steve Nuchia (713) 334 6720 voice
{housun,{soma,academ}!uhnix1}!nuchat!steve
(713) 334 1204 2400N81 "trouble" sends anonymous mail to me.
r...@tiger.uucp
Not to mention /usr/spool/uucppublic files end up readable by the world
normally and owned by uucp. It seems to me that the final path to a person's
received files and the files themselves should be owned by him and readable
by him only. This does not require a setuid(), just a chmod followed by a
chown (at least in shell, I have not used the C routines enough to know off the
top of my head, and of course this would be a modification to the uucico C
source).
Randy
Doug Gwyn
>I don't know the answer but I certainly like the idea of "cd a/b; cd .."
>being equivalent to "cd a" whether "a" is a mount point, RFS mount point
>or a symbolic link.
It seems to me we're gradually wobbling our way towards the idea that
the "current working directory" is really just a "prefix" to be used
for relative path resolution. This approach is taken by some OSes
(Apple ProDOS being one I'm quite familiar with) and it seems to work
fine. Indeed, it generalizes nicely so that one can have a handful of
current prefixes simultaneously available, e.g. one for libraries, one
for commands, etc.
Of course UNIX implementations of the "prefix" would remarkably
resemble what they're doing already for the cwd. (One doesn't have
to ACTUALLY prepend a prefix text string then look up all inodes in
the path starting at the root every time one opens an object!)
With the prefix approach, the natural meaning of "cd" is "set new
prefix", and "cd .." most naturally would mean "trim off the most
local pathname component from the current prefix".
I recommend that we move UNIX toward prefixes as a better naming
concept than "working directory".
Chris Torek
>"#!" was not concocted merely to solve the C shell vs. Bourne shell
>problem.
And indeed, it does more:
% egrep uucp:: /etc/passwd
uucp::16:16:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/recording
% cat /usr/lib/uucp/recording
#! /bin/awk NR > 1 { print }
There is no general-use uucp account on this machine.
Machines which poll us are assigned individual accounts.
If you wish to establish a uucp connection, call
(301) 454-7690 and ask for Fred Blonder or Chris Torek.
%
`#! /bin/sed 1d' works too.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: ch...@mimsy.umd.edu Path: seismo!mimsy!chris
Jonathan Clark
>> many symlinks or networked file systems I had to go through to get there.
>Which can, in most cases, be done by the shell interpreting the "cd"
>command; the question is whether one should add extra stuff to the
>kernel to make this work invisibly? I tend to agree with what was
>given as Dennis Ritchie's position, which was "no".
I'd disagree. Yes, I realize that the kernel would then have to keep
track of where you are in the file system, that's unfortunate.
However, adhering to this does maintain the tree-structure of the
current file system. I would also argue that when 'cd'ing through
hard-linked directories then the kernel should, following the same
model, keep track of how you got there. There has to be a Buckeroo
Banzai quote in there somewhere.
symlinks are then available to be used as methods of mapping /usr/src into
/big-file-server/usr/src, thus hiding icky details of which file systems
are where on an extended system or set of systems from the user. Which is
not to say that they can't be used for other things.
The model given above does modify the concept of 'absolute position in
the file system', but I was unable in 30 seconds or so to work out
what if anything this might break. Loop-detecting 'find's, possibly,
but they should be easily modified (also they are fairly new). In
fact, if anything they should be easier to write, since to detect a
loop one only has to keep the duple <file-system, inode> for each
ancestor directory, and compare the current two values. A match equals
a loop. How would a loop-detecting 'find' work over a symlink if `pwd`
returned the position relative to the mount point of the file system?
This is not thoroughly thought out, I admit, so go ahead and shoot me down.
Jonathan Clark
>> On a similar note, for the people who are expounding starting one's
>> shell scripts with "#! /bin/csh", the logical continuation of this is
>> to start one's C programs with "#! /bin/cc", and so on.
>
>No. Executable files begin with a magic number, which indicates the
>interpreter to be used to execute that file.
I was insufficiently precise - I meant that the continuation was that
one should start one's C *source* programs with "#! /bin/cc" then
instead of saying 'cc file.c' one would just say 'file.c' and the
kernel would automatically invoke the correct interpreter. This is not
a bad feature, but it isn't what I understand as UNIX (though it probably
is already implicit in BSD systems).
> partial superset language processors
This based on the perceived knowledge that there are Bourne shell
mechanisms not supported by C shell (which I admit I have never used)
- if this is not the case then I withdraw the comment.
>> Perhaps csh should have been made to interpret a strict superset of the
>> Bourne shell,
>
>Considering that the C shell, I believe, antedated the Bourne shell
>(or, at least, the public availability of the Bourne shell), this
>might not have been practical.
Well, I am by no means an old hand at UNIX, but I remember using the
Bourne shell or something very like it (and written in Algol, more or
less) in 1977 on my v6 system.
As an extension of the concept of magic numbers I can see the value of
the mechanism, perhaps UNIX should have had a system call "hardware"
which meant "run this file on the machine's actual real CPU"? Then
everyone would have got used to feeding their input through *some*
sort of language processor (and example of which is hardware).
Michael Khaw
>biggest problem I had was understanding what I got if I stat(2)ed a symbolic
>link. My USG-Unix brain says I should get a stat structure saying I found
>a symbolic link. But I don't seem to believe this is the way it works.
>
"man 2 stat" on my Ultrix system says that
- stat(2) gets you information on the file
- lstat(2) gets you information about the symlink if the file
is a symlink, otherwise it's just like stat()
so stat() doesn't let you know if you gave it a symlink, because it returns
information about the target of the symlink.
Mike McNally
>Listen guys, if I say 'cd a/b/c/d/e;cd ..' then I am now in a/b/c/d,
>regardless of how many symlinks or networked file systems I had to go
>through to get there. Anything else is brain-damaged.
Well gee, if I cd to somewhere and then cd to .., I expect my current
directory to be changed to the parent of the previous wd. I have never
been confused by this, and I'm amazed at the amount of people who are.
>
>On a similar note, for the people who are expounding starting one's
>shell scripts with "#! /bin/csh", the logical continuation of this is
>to start one's C programs with "#! /bin/cc", and so on.
Wow, on my system I have to compile my C programs. This process results
in an executable file with (guess what) a magic number at the beginning.
> Writing a
>language processor which is a partial superset of an existing standard
>is one thing, and quite OK in my book; hacking the kernel to support this
>automagically is quite another.
The kernel supports *any* interpreter. I can start a makefile with
#!/bin/make and that will work; I can start an awk script with
#!/bin/awk and that will work; I can put #!sort at the top of a file,
change its mode, then run it to see the sorted contents. And of
course, I can start a C sourcefile with #!/bin/cc and then run it to
invoke the compiler (which will complain about the illegal preprocessor
command, I think). The #! "hack" was not just for csh.
> Perhaps csh should have been made to
>interpret a strict superset of the Bourne shell, so that normal scripts
>work under it, and then csh scripts should have been interpreted via
>"csh script"? Then we wouldn't have this problem.
Please. There is more to running programs than what is typed from a
shell. What about other programs that want to run somthing via
execve? Are they supposed to figure out what interpreter to use by
calling "file"???
>Jonathan Clark
>[NAC,attmail]!mtune!jhc
--
Mike McNally, mercifully employed at Digital Lynx ---
Where Plano Road the Mighty Flood of Forest Lane doth meet,
And Garland fair, whose perfumed air flows soft about my feet...
uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474
John Redden
controversy.
We run a number of flavors of Unix at TTI. The most popular are BSD based
thus symbolic links (as opposed to hard links) are used often in our work.
Typically we use symbolic links to create a view (or schema if you will)
of one of our file systems to conform to another organizations (equally
valid) view of a file system. This is particularly useful in a *heavily*
cross mounted NFS environment.
Very early in the game we discovered the semantic anomally of cd ..
after a cd to a directory that was an object of a symbolic link. This
is not a great problem as long as the semantic behavior is understood. And
actually its easy to create an alternate "cd .." to the subject directory
of the symbolic link.
It would be nice to have a consistant syntax for cd:
cd .. takes you the real parent (as it currently does)
cd ... takes you to the first symbolic link
cd .... takes you to the second symbolic link
cd ..[.]*. takes you to the ith symbolic link
One bad side effect (no considering implementation problems) would be
that ... and the like would become illegal file names.
Comments?
These are solely my opinions and not the people whom I work with.
Elein Mustain
> In article <6...@nu3b2.UUCP> you write:
> >
> >What is a "symbolic" link?
> >
>
>
I had planned to save the net from this flame but you didn't include
your mail path. Use the 'n' key if you don't want to hear about manners.
FLAME:
Geoff, people like you give wizards a bad name. I have found this
group to be extremely polite and useful. There will always be
misdirected queries from people. The most helpful way to redirect
them is to mail them an answer and suggest that they try the
comp.unix.questions group.
> 1) You posted to comp.unix.wizards which is supposedly for "advanced"
> questions [1]. You should at least have had the sense that your
> question was of a basic nature, i.e. maybe fit for comp.unix.questions.
> You are "fairly well informed" about what? AIDS? Aren't we all by now?
>
In this case, since the discussion was here, the question was not out
of order. The analogy about AIDS is completely inappropriate.
> 2) The "man" command can be useful. It's actually faster than sending
> junk queries over the net -- though the output is rather predictable. :-(
> Presuming that you're not on some relic UNIX system without symbolic
> links, try: man ln
>
A gentle suggestion always works better. Unless you are so insecure that
you must assert your shakey superiority.
> 3) Your spelling is atrocious, especially the following mapped files
> discussion. Please run your letters through "spell",
> or better still "| head -0" :-)
I seem to remember a part in the net etiquette document (DID YOU EVER READ IT?)
about spelling flames. I direct you to read the new user net documents.
Since you feel qualified to answer questions here I can't understand
why you missed it. Or are procedures and proper posting only applicable to
people you think are neophytes.
> [1] Here's to calling the kettle black, but I couldn't mail to nu3b2?
We could do without this ancient racist cliche.
> Geoff
Now back to our regularly scheduled group discussions.
--Elein
--
========
A. Elein Mustain UUCP:{stcvax,isis,ihnp4}!onecom!pnn!elein
TelWatch, Inc. @ Oakland,CA VOICE:(415)654-7435
My opinions are my own and I reserve the right to change my mind.
Roy Smith
> It seems to me we're gradually wobbling our way towards the idea that
> the "current working directory" is really just a "prefix" to be used
> meaning of "cd" is "set new prefix" [...]
Indeed, this is exactly the way I explain "cd" to people just
learning Unix. I find the approach to be simple and intuitive, and havn't
yet run into anyplace where the "set prefix" abstraction has caused any
confusion. Of course, most of my users just want to get their work done
and don't care about the details of stat(2) and such.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
Malcolm Slaney
>It seems to me we're gradually wobbling our way towards the idea that
>the "current working directory" is really just a "prefix" to be used
>(Apple ProDOS being one I'm quite familiar with) and it seems to work
>fine. Indeed, it generalizes nicely so that one can have a handful of
>current prefixes simultaneously available, e.g. one for libraries, one
>for commands, etc.
>
I think it is a lose. Just about every user operation has a different
concept of the current directory and I have yet to figure out their rhyme
or reason. In some case, like editor buffers, it is pretty obvious but
in other cases it isn't.
For example the "copy file" command has a default directory which generally
is identical to the last directory used. I'm sure if I did a bit of
investigation I could figure it out its exact behaviour but that really
shouldn't be necessary.
At least Symbolics does show you the current default directory/pathname
whenever you have to enter something.
Malcolm
Simon Brown
>programs, not just shells. (It also permits interpreted programs to
>be set-UID, assuming you trust the interpreter's mechanisms to the
>degree necessary to make set-UID interpeted programs safe. Prior to
>4.3BSD, there were two very large security holes that rendered
>set-UID shell scripts, at least, unsafe; those two holes were closed
>in 4.3BSD, but there could well be others.)
>
>which is a partial superset of an existing standard"? What it
>supports is executing shell scripts as ordinary programs *without*
>having to ensure that all programs that might try to execute that
>script use "exec[lv]p" instead of "exec[lv]". The latter is somewhat
>nice, considering that not all programs *do* use "exec[lv]p".
>
Unfortunately, execution of a "program" only makes sense from within an
interpreter environment (such as sh, csh, ...). After all, the command
"/bin/cat" that gets executed by a "#!/bin/cat" interpreter could have
widely different interpretations depending on who is executing it.
Luckily, all shells treat pathname-commands as being "execv that pathname",
but this does limit the sort of commands that may be issued via a
#! directive.
I would quite like to use pipes, i/o redirection, shell-variables, etc... in
a #! - for example
#!(sed 1d | tbl | nroff -ms | lpr)
.PP
Hello.
.TS
a table
.TE
[etc...]
in a file, to automatically run its contents through "tbl" and "nroff" and
print out the result, whenever the file is executed.
But there is no provision for this sort of syntax in a #!, which is a pity.
I guess ``#!/bin/sh -c "sed -d $1 | tbl | nroff -ms | lpr"'' might work,
but this is very ugly.
%{
Simon.
%}
--
----------------------------------
| Simon Brown | UUCP: seismo!mcvax!ukc!its63b!simon
| Department of Computer Science | JANET: si...@uk.ac.ed.its63b
| University of Edinburgh, | ARPA: simon%its63b....@cs.ucl.ac.uk
| Scotland, UK. |
---------------------------------- "Life's like that, you know"
Doug Gwyn
>... I realize that the kernel would then have to keep
>track of where you are in the file system, that's unfortunate.
The kernel has to do this anyway, in order to resolve relative
pathnames during an open().
Bruce G Barnett
> #! /bin/awk NR > 1 { print }
>
Good example. But I cannot figure out how ELSE to use this feature
with awk. How can I create a t.awk that contains an awk script,
and make it executable?
That is, in file t.awk, I have
#!/bin/awk -f t.awk
No matter what I try, I get the "bailing out near line 1" error.
And could someone explain to me why the first line isn't treated as a
comment within the awk script?
--
Bruce G. Barnett (bar...@ge-crd.ARPA) (bar...@steinmetz.UUCP)
--
"The difference between a Buddha and an ordinary man is that one knows
the difference and the other does not."
Skip Egdorf
When I moved a group of users from a Multics to a brand new 11/70
Version 6 system, there was little trauma. The editors were similar,
the languages were different (PL/I vs C) but that was expected and
managed by all concerned.
The main confusion was with the different semantics of links.
You see, Multics used what are now called soft links, and everyone
complained how the natural, normal way links should work was broken in
UNIX. I had to explain several times why, when a common link was made
to a program by several users, and then the owner re-built the
program, the other users still got the old version. How un-natural
could you get????
(I think that I was the only one who did more than just compile
user code on the Multics. I missed, and still miss SO MANY of the
features of that environment for development... However, that is another
article, and none of the loss was felt by the other users except for
link semantics)
I finally just told the users that Multics links were Multics links
and Unix links were Unix links and that they were just DIFFERENT!
Either were a tool for getting a job done, and there was little use
in worrying about why the Multics orange didn't make good pies and cider,
and why the Unix apple produced very poor marmalade.
Now we have a system with both sorts of different and useful tools,
and the argument goes on in re-invented form.
My two cents worth is: Don't try to put hard-link semantics onto
symbolic links, and don't try to put symbolic-link semantics onto
hard links. They are both needed concepts. The cost of the additional
power is the increased semantics of the file system.
Skip Egdorf
h...@lanl.gov
Michael Khaw
->It would be nice to have a consistant syntax for cd:
->
->cd .. takes you the real parent (as it currently does)
->cd ... takes you to the first symbolic link
->cd .... takes you to the second symbolic link
->
->cd ..[.]*. takes you to the ith symbolic link
->
->One bad side effect (no considering implementation problems) would be
->that ... and the like would become illegal file names.
->
->Comments?
What about all the shell scripts that look for ".??*" expecting not to clobber
"." and ".."? They are for sure going to clobber "..." etc.
der Mouse
> There is a difference between saying "You can't because it is
> impossible" and saying "You can't because I won't let you." One of
> the big wins in Unix is that it doesn't put up artificial
> restrictions.
Well put.
> [...] what does your ls do when you say "ls -lFL" for a symlink
> pointing at non-existant file?
Ours ignores the -L option, that is, it lists the symlink rather than
the file it points to.
> Chris Torek writes: (from the /dev/stdin discussion)
>> One of the wonderful things about Unix is its simple naming scheme.
>> [...] In V8 processes became files, through /proc. This is the
>> right way to go.
> Hey, does this mean I could have a symlink to a process??
> (If I had v8) Cosmic!
Hey, does this mean that fork() is just a special case of mknod()?
exit() just a special case of unlink()?
Yow! Are we having FUN yet?
der Mouse
(mo...@mcgill-vision.uucp)
David Zink
]It seems to me we're gradually wobbling our way towards the idea that
]the "current working directory" is really just a "prefix" to be used
]for relative path resolution. This approach is taken by some OSes
](Apple ProDOS being one I'm quite familiar with) and it seems to work
]fine. Indeed, it generalizes nicely so that one can have a handful of
]current prefixes simultaneously available, e.g. one for libraries, one
]for commands, etc.
]Of course UNIX implementations of the "prefix" would remarkably
!resemble what they're doing already for the cwd. (One doesn't have
!to ACTUALLY prepend a prefix text string then look up all inodes in
!the path starting at the root every time one opens an object!)
]
]With the prefix approach, the natural meaning of "cd" is "set new
]prefix", and "cd .." most naturally would mean "trim off the most
]local pathname component from the current prefix".
]
]I recommend that we move UNIX toward prefixes as a better naming
]concept than "working directory".
Yay for Apple ProDOS MSDOS etc. You're right ! we should change UN*X to
work more like those beautiful OS'es. And when you type
cd /usr/JO
and root types
mv /usr/JO /usr/JMO
and you type
cd .
and The prefix /usr/JO/ is attached to it to make /usr/JO/. and the shell says
'.' NOT FOUND.
you're going to be so glad you got UN*X to work like a toy manufacturers
single-user operating system.
Of course the idea of prefixes for commands is $PATH that for libraries is
fixed at /usr/lib but since all unix people except wizards use makefiles
it may not be all that useful. Besides, following usual eunuch tradition
each different program would have it's own environment variable it would use
for this.
As far as cd .. goes, you can't usually unmount the filesystem containing a
directory which someone has open, say as cwd; however imagine
mount /dev/hd7 /mnt1
mkdir /mnt1/lice /mooseteeth
ln -s /mooseteeth /mnt1/lice/pointy
cd /mnt1/lice/pointy
umount /dev/hd7
cd ..
Nuff said?
John Owens
> I recommend that we move UNIX toward prefixes as a better naming
> concept than "working directory".
And indeed, this is what VMS does, where the equivalent of "cd" is
SET DEFAULT
and it sets the default prefix for that process. If anyone tries to
implement this, watch out for the misfeature that VMS has: you can SET
DEFAULT successfully to any well-formed string, but you only find out
whether or not the directory exists when you try to use it.
Also, be aware that this will change the semantics of the following:
User 1 User 2
cd /dir/one
touch file
mv /dir/one /dir/one.bak
mkdir /dir/one
/bin/pwd
ls
Currently, pwd will say "/dir/one.bak", and ls will show "file". If
you implement directories as prefixes, pwd will say "/dir/one" and ls
will show nothing. Which of these is most desirable is open to
question....
--
John Owens Old Dominion University - Norfolk, Virginia, USA
jo...@ODU.EDU old arpa: john%odu...@RELAY.CS.NET
+1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john
Dave Brown
>> One system I maintained (running a Unisoft port) used the sticky bit
>> on a 777 directory to mean "anyone can create a file here, but only
>> the owner can delete it". This was used on /tmp and /usr/tmp.
One can simulate this by writing an "append" program and putting
a link in the applicable directory. I published one last winter
in mod.sources, so it must be easy (:-))
--
Computer Science | David (Collier-) Brown
loses its memory | Geac Computers International Inc.
every 6 months | 350 Steelcase Road,Markham, Ontario,
-me. | CANADA, L3R 1B3 (416) 475-0525 x3279
Guy Harris
> one should start one's C *source* programs with "#! /bin/cc" then
> instead of saying 'cc file.c' one would just say 'file.c' and the
> kernel would automatically invoke the correct interpreter. This is not
> a bad feature, but it isn't what I understand as UNIX (though it probably
> is already implicit in BSD systems).
But "/bin/cc" *isn't* a "C interpreter" in the commonly-understood sense of
the word "interpreter". If you run "/bin/cc" on a piece of C source
code, it produces an object (no pun intended) that will, when
executed by the machine, do what the C program was intended to do; it
will not itself do that.
> > partial superset language processors
>
> This based on the perceived knowledge that there are Bourne shell
> mechanisms not supported by C shell (which I admit I have never used)
> - if this is not the case then I withdraw the comment.
There are Bourne shell mechanisms not supported by the C shell.
However, there are also C shell mechanisms not supported by the Bourne
shell. (Also, neither language is a *syntactic* subset of the
other one.)
> >Considering that the C shell, I believe, antedated the Bourne shell
> >(or, at least, the public availability of the Bourne shell), this
> >might not have been practical.
>
> Well, I am by no means an old hand at UNIX, but I remember using the
> Bourne shell or something very like it (and written in Algol, more or
> less) in 1977 on my v6 system.
The first version of the Bourne shell publicly released by AT&T in a
UNIX system was the one released with V7 in 1979. I believe the work
on the C shell was started on V6 (I think there are fragments of V6
shell code still in the C shell).
> As an extension of the concept of magic numbers I can see the value of
> the mechanism, perhaps UNIX should have had a system call "hardware"
> which meant "run this file on the machine's actual real CPU"? Then
> everyone would have got used to feeding their input through *some*
> sort of language processor (and example of which is hardware).
Do you mean "system call" or "command" (there already is a family of
calls like that, namely "execve", etc.)? Some systems *do* have such
a command, often named "run"; those systems either don't allow you to
add new commands to their command languages or they require you to do
something special to do so.
If UNIX did have a "run" command, and didn't oblige people to use it,
would people have used it if they could also have run a program just
by typing the program's name? If it required you to use "run", would
people have been as eager to add new commands, since doing so would
require you to add an alias (e.g., aliasing "newcommand" to "run
newcommand" or "sh newcommand") if you wanted to use it without
typing an extra noise word "run" or "sh" in front of it (and if you didn't
have aliases, you'd really lose)?
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com
Bruce G Barnett
>That is, in file t.awk, I have
>
> #!/bin/awk -f t.awk
>
>No matter what I try, I get the "bailing out near line 1" error.
Yes, I did try #!/bin/awk -f
I STILL get the "bail" error:
Exhibit A, Ultrix 1.2:
csh >cat t.awk
#!/bin/awk -f
BEGIN { print "Begin"}
{
print;
}
END { print "End"}
csh> awk -f t.awk </dev/null
Begin
End
csh> t.awk
awk: syntax error near line 1
awk: bailing out near line 1
I also tried "#!/bin/awk -f -"
Does someone have an invocation that WORKS?
Why am I "bailing out"?
Brandon Allbery
+---------------
| In article <71...@mimsy.UUCP> ch...@mimsy.UUCP (Chris Torek) writes:
| Good example. But I cannot figure out how ELSE to use this feature
| with awk. How can I create a t.awk that contains an awk script,
| and make it executable?
|
| That is, in file t.awk, I have
|
| #!/bin/awk -f t.awk
|
| No matter what I try, I get the "bailing out near line 1" error.
That isn't quite valid. Firstly, some systems (not yours, apparently)
require a space between the #! and the command name.
Second, you should not include the program name; the kernel (or bexec if
you got it) adds it automatically. Both also package everything after the
command name in the #! sequence as a SINGLE argument. As a result, awk is
seeing the command:
/bin/awk '-f t.awk' t.awk
which means "for all lines in t.awk which for which the condition "-f t.awk"
is true, print the lines." Unfortunately, "-f t.awk" is not a valid condition;
it's a syntax error. Remove the "t.awk" from the top line of your script and
you will be all set.
++Brandon
--
---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ----
Brandon S. Allbery <BACKBONE>!cbosgd!ncoast!allbery
aXcess Company {ames,mit-eddie,harvard,talcott}!necntc!ncoast!allbery
6615 Center St. #A1-105 {well,sun,pyramid,ihnp4}!hoptoad!ncoast!allbery
Mentor, OH 44060-4101 necntc!ncoast!all...@harvard.HARVARD.EDU (Internet)
+01 216 974 9210 ncoast!all...@CWRU.EDU (CSnet)
Older than any person of lesser age
symlink/.. is a user-interface question. Therefore I claim that
any special interpretation should be placed in the shell. For
myself, a csh user, I find that the following is just dandy:
alias up cd \$cwd:h
Then I can use it:
% cd /etc/yp
/etc/yp ~
% pwd
/usr/etc/yp
% up
% pwd
/etc
Hands off namei()!
________________________________________________________
Matt University ma...@oddjob.uchicago.edu
Crawford of Chicago {astrovax,ihnp4}!oddjob!matt
der Mouse
[ incidentally Eduardo, I suggest you get on your netnews admins to get
rid of the extra . in that "..UUCP". ]
> I don't know the answer [to the Right Way to handle symlinks] but I
> certainly like the idea of "cd a/b; cd .." being equivalent to "cd a"
> whether "a" is a mount point, RFS mount point or a symbolic link.
It's not the symlinkness of a that matters but that of b. I agree,
it's a nice idea, but it sounds to me more like a feature of cd than of
symlinks. I've yet to hear a cohesive explanation of how symlinks
would work that includes this feature as a side effect, that is, in a
way that doesn't require special-casing cd.
der Mouse
(mo...@mcgill-vision.uucp)
Allyn Fratkin
> alias up cd \$cwd:h
i use an alias almost like this, but mine looks like:
alias .. 'cd /$cwd:h'
the leading / before the $ is important. with your alias, typing
"up" from a directory like /etc will move you to your home directory,
not to / as would be expected.
unfortunately, this doesn't help programs trying to open files with ..
in the path.
--
From the virtual mind of Allyn Fratkin al...@sdcsvax.ucsd.edu or
EMU Project {ucbvax, decvax, ihnp4}
U.C. San Diego !sdcsvax!allyn
Daniel R. Levy
< In article <21...@sun.uucp> guy%goro...@Sun.COM (Guy Harris) writes:
< >"#!" was not concocted merely to solve the C shell vs. Bourne shell
< >problem.
< And indeed, it does more:
< % egrep uucp:: /etc/passwd
< uucp::16:16:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/recording
< % cat /usr/lib/uucp/recording
< #! /bin/awk NR > 1 { print }
< `#! /bin/sed 1d' works too.
This is like using a cannon to kill a gopher.
Why not
/bin/cat << !
[message]
!
which will also work on systems other than "Berserkeley" UNIX.
--
|------------dan levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
| an engihacker @ | vax135}!ttrdc!ttrda!levy
| at&t data systems division | Disclaimer: try datclaimer.
|--------skokie, illinois--------|
Doug Gwyn
>My two cents worth is: Don't try to put hard-link semantics onto
>symbolic links, and don't try to put symbolic-link semantics onto
>hard links. They are both needed concepts.
Another evaluation might be: "Whenever two similar but different
ways of doing a task are implemented on the same system, semantic
problems occur where their domains overlap."
It seems that symlinks were an attempt to overcome the restriction
against linking across different mounted file systems. Surely some
other approach fully compatible with hard links could have been
found. If it had, then Korn's ".." interpretation would still be
operative for whatever approach might have been adopted, just as it
already is for the root of a mounted filesystem.
Doug Gwyn
>Nuff said?
Far too much for a message with zero information content.
If you have a valid technical point to make, make it, but
just trying to be cute is not appreciated.
Bruce G Barnett
>
> #!/bin/awk -f
>
>No matter what I try, I get the "bailing out near line 1" error.
Thanks for the many cards and letters.
The problem is another Ultrix 1.2 'feature'. It works properly on Suns,
Pyramids, 4.3bsd, and Ultrix 2.0.
David Elliott
>In article <71...@mimsy.UUCP>, ch...@mimsy.UUCP (Chris Torek) writes:
>< And indeed, it does more:
>< % egrep uucp:: /etc/passwd
>< uucp::16:16:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/recording
>< % cat /usr/lib/uucp/recording
>< #! /bin/awk NR > 1 { print }
>< [message]
>Why not
>
>/bin/cat << !
> [message]
>!
>which will also work on systems other than "Berserkeley" UNIX.
What? You mean that your /etc/password will allow you to put multiple
lines in the shell field? What you suggest is that
uucp::16:..:/bin/cat << !
[message]
is a valid entry in the password file.
The point was that with #! you can use shell scripts or any other
scripts as login shells or anywhere an executable program can go.
Sure, you could say
#!/bin/sh
/bin/cat << !
[message]
!
and have it work, but you could not simply say
/bin/cat << !
[message]
!
and have it work unless login(1) executes the script vi sh.
The fact that #!/bin/awk or #!/bin/sed or #!/usr/ucb/tail +2 will
work is due to the generality of the #!, and generality is a big
win.
--
David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce
The Computer Grue
> Yes, I did try #!/bin/awk -f
>
> I STILL get the "bail" error:
> Exhibit A, Ultrix 1.2:
>
> csh >cat t.awk
> #!/bin/awk -f
> BEGIN { print "Begin"}
> {
> print;
> }
> END { print "End"}
> csh> awk -f t.awk </dev/null
> Begin
> End
> csh> t.awk
> awk: syntax error near line 1
> awk: bailing out near line 1
>
You are not going to f**king believe this. I got curious enough
about your question to start fiddling (I use several awk 'shell
scripts' and they work fine for me) and I think I figured out what
the problem is. You have a space (that's right, hex 0x20, char ' ',
whatever) immediately after your '-f'. This seems to be a problem
because the kernel is passing '-f ' (as opposed to '-f', which is what the
shell would pass it) to awk as it's first argument and it doesn't
seem to know how to deal with a space immediately after a flag.
Since the argument parsing is done in the kernel for the 'interpeter
line' of shell scripts and in the shell for straight command line
arguments, awk's getting a little hosed when called through the
'exec' mechanism.
I confirmed this hypothesis two ways. First, I deleted the space
at the end of the first line and Bruce's program runs fine. That is to
say, the program:
-------------------------
#!/bin/awk -f
BEGIN { print "Begin"}
{
print;
}
END { print "End"}
---------------------
works fine for me (check it; no space) where the original program
does not. Second, I invoked "awk '-f ' awk.inp" and reproduced the
syntax error message.
Weird. I'm not sure whether I'd call this a bug in the kernel
processing of the '#!' magic number, or whether awk should be able
to handle '-f ' as an argument. Bad synergy.
-- Randy Smith
--
Randy Smith @ NCI Supercomputer Facility
c/o PRI, Inc.
PO Box B, Bldng. 430 Phone: (301) 698-5660
Frederick, MD 21701 Uucp: ...!seismo!elsie!ncifcrf!randy
John P. Nelson
> ^^^^^^^^^^^^^^^^^^^^
>csh >cat t.awk
>#!/bin/awk -f
I think the problem is relatively simple. I used "SUN" cut+paste to grab
the script in question, and I had the same problem. I then noted that the
#!/bin/awk line had a BLANK at the end of the line. I have to assume that
when the kernel sees the blank, it inserts a "null" argument.
Anyway, after deleting the extraneous blank, the script worked fine!
David Zink
Sorry, I usually have ~30 mins/week to read and respond to EMAIL news etc.
and I get a little hot about things like people considering changing the
kernal to support strange interpretation of '..'. The information content
Intended was that because symlinks are used to cross filesystems '..'-as-last
part-of-however-we-got-here can become meaningless. This cannot happen
under the current implementation. Will this create new problems? I also
expect that the correct Unix way to handle the problem would be to
make it illegal to umount a device that has been cd'ed through. I have yet
to see a well thought out proposal on the subject so I assume we are in the
throw out possible objections before we have to start whining at ATTETC that
they overlooked things.
I also should have kindly pointed out that UNIX doesn't even have a current
working directory concept, but a current working inode, which is nice because
it helps the guru's to be able to patch things up without having to bring the
system down.
And I use silly examples instead of just describing ideas because they are
less open to {mis,}interpretation. Just imagine typing them in and watch
them perform.
I agree I could have used better judgement in the choice of directory names,
but I didn't.
Too much said?
William E. Davidsen Jr
|In article <6...@nu3b2.UUCP> you write:
|>
|>I have been reading these articles since I joined USENET [some 1.5 weeks
|>ago] I feel that I am fairly well informed but...
|>
|>What is a "symbolic" link?
|>Is is different from a regular link?
|>am I crazy? :-)
|>Did I miss something important in my education? 8-)
|>
|>Someone please respond or mail me an explination.
|> Thanks.
|>
|>Robert.
|
|Sorry to FLAME you but...
|
|1) You posted to comp.unix.wizards which is supposedly for "advanced"
| questions [1]. You should at least have had the sense that your
| question was of a basic nature, i.e. maybe fit for comp.unix.questions.
| You are "fairly well informed" about what? AIDS? Aren't we all by now?
Nice bit of gratuitous insult. If he doesn't know what it is, how can he
know if it's advanced or not? This is where the discussion is, he
assumed that this was where he should ask.
|
|2) The "man" command can be useful. It's actually faster than sending
| junk queries over the net -- though the output is rather predictable. :-(
| Presuming that you're not on some relic UNIX system without symbolic
| links, try: man ln
It may come as a vast suprize to you, but there are more people using
SysV than BSD. There are also more copies of Xenix in use than any other
implementation, and that doesn't even *include* the man pages!
Of course the comment about relic operating systems is "real technical".
You must be one of the people who tie up the net every few months with
"my o/s is better than your o/s".
|
|3) Your spelling is atrocious, especially the following mapped files
| discussion. Please run your letters through "spell",
| or better still "| head -0" :-)
Being such a hot shot, why don't you pipe your incoming mail through
spell? You could use style and dict too, if you like. Why all the flames
about a simple question?
|
|---
|[1] Here's to calling the kettle black, but I couldn't mail to nu3b2?
|
|Geoff
I can't use you address, either.
--
bill davidsen (we...@ge-crd.arpa)
{chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
William E. Davidsen Jr
>In article <1...@wrs.UUCP>, ge...@wrs.UUCP (Geoff Espin) writes:
>> In article <6...@nu3b2.UUCP> you write:
>> >
>> >What is a "symbolic" link?
>> >
... much flaming and flames of flaming deleted ...
>
>> [1] Here's to calling the kettle black, but I couldn't mail to nu3b2?
>We could do without this ancient racist cliche.
The original saying is "like the pot calling the kettle black". I don;t
see a lot racist here. The saying originated when cooking was done over
wood fires, and refers to a person with a bad habbit complaining about
the same bad habbit in someone else.
... signatures deleted except mine ...
Doug Gwyn
>'..'-as-last part-of-however-we-got-here can become meaningless. This cannot
>happen under the current implementation.
Since I don't understand that logic (the current symlink implementation does
not handle .. that way), let me paraphrase the argument. I think you're
saying that if the underlying linkage structure (hard or soft) is rearranged,
the "current working directory" concept acquires some warts (e.g. one's actual
filesystem location could change with the cwd remaining fixed). This is true
of ANY implementation; the only difference would be the particular nature of
the warts. I have more than once found that "cd .." (old style) did not get
me into an existing location. Fortunately this is a relatively unusual
situation.
The only reason that current implementations get away with keeping just the
current inode (and device) is that that could serve as an abbreviation for
the current path. With /proc, /n/face, and other oddball types of file system,
it is rapidly becoming necessary to find some other way to record the "current
working directory". A path prefix is certainly the simplest I can think of.
(As I remarked earlier, it can also be generalized nicely to provide a NEW
facility that UNIX hasn't had before. It also makes getcwd() a simple task.)
Daniel R. Levy
< In article <17...@ttrdc.UUCP> le...@ttrdc.UUCP (Daniel R. Levy) writes:
< >In article <71...@mimsy.UUCP>, ch...@mimsy.UUCP (Chris Torek) writes:
< >< And indeed, it does more:
< >< % egrep uucp:: /etc/passwd
< >< uucp::16:16:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/recording
< >< % cat /usr/lib/uucp/recording
< >< #! /bin/awk NR > 1 { print }
< >< [message]
< >This is like using a cannon to kill a gopher.
< >Why not
< >
< >/bin/cat << !
< > [message]
< >!
< >which will also work on systems other than "Berserkeley" UNIX.
< What? You mean that your /etc/password will allow you to put multiple
< lines in the shell field? What you suggest is that
< uucp::16:..:/bin/cat << !
< [message]
< is a valid entry in the password file.
No, no, that's not what I meant. I meant to use a script containing that text.
< The point was that with #! you can use shell scripts or any other
< scripts as login shells or anywhere an executable program can go.
I looked at the source for /bin/login on a SVR2 machine (3B20). It uses
execlp() to execute the login shell, so it can be a shell script. (This
is probably a moot point anyhow since System V doesn't interpret "#!".)
< ...but you could not simply say
<
< /bin/cat << !
< [message]
< !
<
< and have it work unless login(1) executes the script vi sh.
I also tested a script containing just
/bin/cat << !
[message]
!
as a "login shell" upon a real live BSD 4.2 machine. Surprise, surprise,
it worked just dandy. I also tried putting in a "ps -axww" and it showed the
script being executed by /bin/sh. I tend to doubt that the machine I performed
this test upon is nonstandard in that respect.
< The fact that #!/bin/awk or #!/bin/sed or #!/usr/ucb/tail +2 will
< work is due to the generality of the #!, and generality is a big
< win.
< --
< David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce
In some cases this IS nice. But in the example given, it was still like using
a cannon to kill a gopher.
Chris Torek
>... I then noted that the #!/bin/awk line had a BLANK at the end of
>the line. I have to assume that when the kernel sees the blank,
>it inserts a "null" argument.
No, for the kernel code that handles `#!' magic numbers is purposely
extremely simple. It no longer requires exactly one blank in the
right places (if indeed it ever did so), but it creates at most
one `argv' argument. The call
execl("bin/foo", "argv0", "argv1", (char *)0),
where file foo begins with `#! /bin/awk -f ', becomes equivalent to
execl("/bin/awk", "awk", "-f ", "bin/foo", "argv1", (char *)0).
The original argv[0] simply vanishes. The script I gave earlier
began
#! /bin/awk { if (NR > 1) print }
This passes the single argument `{ if (NR > 1) print }' to awk.
The implementation is quite economical; it is most certainly *not*
a full shell parser. If you require a full shell parser, you can
begin your file with `#! /bin/sh'.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: ch...@mimsy.umd.edu Path: seismo!mimsy!chr EP
Mike McNally
>>... I realize that the kernel would then have to keep
>>track of where you are in the file system, that's unfortunate.
>
>The kernel has to do this anyway, in order to resolve relative
>pathnames during an open().
All the kernel needs to keep track of is the inode number of the current
working directory. That's why the code for getwd() is more than just
"ask the kernel for the current wd path".
Perhaps that's what Doug meant.
--
Mike McNally, mercifully employed at Digital Lynx ---
Where Plano Road the Mighty Flood of Forest Lane doth meet,
And Garland fair, whose perfumed air flows soft about my feet...
uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474
Henry Spencer
> it is rapidly becoming necessary to find some other way to record the
V8 /proc preserves the semantics of a normal Unix directory setup *exactly*,
unless I missed something subtle when I read the code. My impression is that
/n/face does likewise. In both cases the directory hierarchy is actually a
figment of the kernel's imagination, but it is a consistent figment with the
same semantics as normal directories.
--
Mars must wait -- we have un- Henry Spencer @ U of Toronto Zoology
finished business on the Moon. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
Chris Torek
>I would quite like to use pipes, i/o redirection, shell-variables, etc... in
>a #! - for example
> #!(sed 1d | tbl | nroff -ms | lpr)
> .PP
> Hello.
> .TS
> a table
> .TE
> [etc...]
`#!' is supposed to be *simple*. . . !
>I guess ``#!/bin/sh -c "sed -d $1 | tbl | nroff -ms | lpr"'' might work,
No, because `#!' can create at most one argument, so this would
pass the string "-c \"sed -d $1 | tbl | nroff -ms | lpr\"" (in C
notation) to /bin/sh. What will work is this:
#! /bin/sh
tbl << '*end*of*text*' | nroff -ms | lpr
.PP
Hello.
...
*end*of*text*
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: ch...@mimsy.umd.edu Path: seismo!mimsy!chris
Guy Harris
> interpreter environment (such as sh, csh, ...). After all, the command
> "/bin/cat" that gets executed by a "#!/bin/cat" interpreter could have
> widely different interpretations depending on who is executing it.
What? You don't have to be a shell to execute a program, so I don't see
where an "interpreter environment" comes into it. "init" and "login"
aren't interpreters in any commonly understood sense of the word
(perhaps in a trivial sense, but that's it), and they execute plenty
of programs.
Furthermore, there is only one interepreter that's *supposed* to
execute "/bin/cat", and that's the one implemented by the hardware,
microcode, and supporting software (kernel, etc.) on your machine.
Yes, if you treat "/bin/cat" as a shell script it will have a
different (and probably not very interesting) interpretation, but so
what?
> I would quite like to use pipes, i/o redirection, shell-variables, etc... in
> a #!
It's not clear that generalizing "#!" so that the interpreter it
executes is an arbitrary shell command or pipeline, and not just a
single program, would be worth the costs. It would require
hardcoding either information about the command syntax of some
particular shell into the kernel, or hardcoding rules telling it to
run the command line in question through a particular shell or shells
into the kernel. Both would increase the complexity of the
implementation, and hardwire things that shouldn't be hardwired.
Furthermore, it would mean that "execve" and company would not be
guaranteed only to change the image running in the current process;
they would have to fiddle the file descriptors of that process, spawn
new processes, etc., etc., etc..
Brandon Allbery
+---------------
| >>No matter what I try, I get the "bailing out near line 1" error.
| > ^^^^^^^^^^^^^^^^^^^^
| >csh >cat t.awk
| >#!/bin/awk -f
|
| I think the problem is relatively simple. I used "SUN" cut+paste to grab
| #!/bin/awk line had a BLANK at the end of the line. I have to assume that
| when the kernel sees the blank, it inserts a "null" argument.
Nope. awk checks for -f with strcmp, but the kernel is bundling the space
into the (single) argument it produces, so the command line ends up being:
/bin/awk "-f " filename
which tells awk to run the program "-f " (which is a syntax error) on the
input file "filename". Zap the space, the strcmp in awk succeeds, and all
is well.
++Brandon
--
---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ----
Brandon S. Allbery <BACKBONE>!cbosgd!ncoast!allbery (NOW!!!!)
aXcess Company {ames,mit-eddie,harvard,talcott}!necntc!ncoast!allbery
6615 Center St. #A1-105 {well,sun,pyramid,ihnp4}!hoptoad!ncoast!allbery
Mentor, OH 44060-4101 necntc!ncoast!all...@harvard.HARVARD.EDU (Internet)
+01 216 974 9210 ncoast!all...@CWRU.EDU (CSnet -- if you dare)
NCOAST ADMIN GROUP Brandon Allbery on 157/504 (Fidonet/Matrix/whatever)
* ncoast -- Public Access UN*X -- (216) 781-6201, 24 hrs., 300/1200/2400 baud *
* ncoast is proud to be carrying alt.all -- contact me for more information *
Brandon Allbery
+---------------
| In article <4...@quacky.UUCP>, d...@mips.UUCP (David Elliott) writes:
| < In article <17...@ttrdc.UUCP> le...@ttrdc.UUCP (Daniel R. Levy) writes:
| < >In article <71...@mimsy.UUCP>, ch...@mimsy.UUCP (Chris Torek) writes:
| < >< And indeed, it does more:
| < >< % egrep uucp:: /etc/passwd
| < >< uucp::16:16:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/recording
| < >< % cat /usr/lib/uucp/recording
| < >< #! /bin/awk NR > 1 { print }
| < >< [message]
| < >This is like using a cannon to kill a gopher.
| < >Why not
| < >
| < >/bin/cat << !
| < > [message]
| < >!
| < >which will also work on systems other than "Berserkeley" UNIX.
| < What? You mean that your /etc/password will allow you to put multiple
| < lines in the shell field? What you suggest is that
| < uucp::16:..:/bin/cat << !
| < [message]
| < is a valid entry in the password file.
|
| No, no, that's not what I meant. I meant to use a script containing that text.
Unfortunately, while /bin/login uses execlp, /bin/su seems to use execl. As
a result, I've been forced to make su-able shells by linking /bin/sh to another
name and checking for "-name" in /etc/profile. (Not that you'd want to do
a "su - uucp".)
Also, using execlp raises the question of how to execute a csh script from
/etc/passwd? (Which may not mean much to you, but csh is d*mned near the
standard shell for BSD.)
all...@ncoast.uucp
+---------------
| In article <5...@its63b.ed.ac.uk> si...@its63b.ed.ac.uk (Simon Brown) writes:
| >I would quite like to use pipes, i/o redirection, shell-variables, etc... in
| >a #! - for example
|
| No, because `#!' can create at most one argument, so this would
| pass the string "-c \"sed -d $1 | tbl | nroff -ms | lpr\"" (in C
| notation) to /bin/sh. What will work is this:
Has anyone considered writing a program which exec's /bin/sh with '-c'?
This would allow:
#! /bin/shio sed -d $1 | tbl | nroff | lpr
Of course, you then need cshrun, etc., which defeats the intent of #!.
Wayne A. Throop
[refering to pathname segment a/b, and relating the case where a
is a symlink to that where b is an NFS or RFS filesystem.]
> It's not the symlinkness of a that matters but that of b. I agree,
> it's a nice idea, but it sounds to me more like a feature of cd than of
> symlinks. I've yet to hear a cohesive explanation of how symlinks
> would work that includes this feature as a side effect, that is, in a
> way that doesn't require special-casing cd.
Ah! I was wondering just how to phrase my misgivings about comparing
these two cases and insisting that they work in the same way, and here
we have it. In the one case, the directory is special. In the other,
something that *points* to the directory is special. It is not clear to
me that the two cases ought to act analogously.
Personally, I don't think symlinks are such a botch as folks make out.
--
"... and every so often he gave a great screeching display, rushing
about and slapping his sides."
--- from "Marooned in Real Time"
--
Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw
Henry Spencer
> unless I missed something subtle when I read the code. My impression is that
> /n/face does likewise. In both cases the directory hierarchy is actually a
> figment of the kernel's imagination, but it is a consistent figment with the
> same semantics as normal directories.
Several people have asked what this is about, so I suppose I should elaborate
a bit. This stuff has been presented in papers at Usenix conferences, but
not everybody's familiar with those.
/proc is V8's replacement for the ptrace() system call and related things.
It's a slightly-odd type of file system. Once mounted, it looks like a
single directory containing a bunch of files with numeric names. If you
open (say) file "12345", you are looking at the address space of process
number 12345. Writes into the file are writes into the address space.
There are ioctls for things like stopping and starting the process, sending
it signals, etc. Access to the files is naturally subject to the standard
Unix file-permission system. The whole thing is actually a figment of the
kernel's imagination, with the "directory" manufactured on the fly whenever
someone tries to read it, and operations on the "files" turned into the
corresponding operations on the processes. Apart from being cleaner than
ptrace(), /proc is also faster.
/n/face is a two-part story. The "/n" part means it's a remote filesystem
mounted over a network. The thing on the other end is actually a server
process, not a filesystem. (I erred slightly when I said that both /proc
and /n/face were figments of the *kernel*'s imagination; /n/face is a figment
of the server's imagination.) The name is because its contents are digitized
faces at various resolutions. As I recall, they do exist on disk, but the
organization of the disk files differs greatly from the directory tree that
appears to exist under /n/face.
In both cases, these odd filesystems look exactly like real ones, down to
things like "." and ".." entries in the directories. You can use all the
standard Unix tools to operate on them.
At least one System V implementation of /proc exists inside AT&T, but it
hasn't made it into any released software that I know of. I believe /n/face
is strictly a V8ism at the moment.
Doug Gwyn
>... Image links are a horse of a different color, And I'd like
>to hear from those in whom my remarks strike a responsive chord.
One way to implement a similar facility is to support "union" mounting
of directories (or more generally, named objects) on each other (as
opposed to the "replacement" mounting we now have). This idea is not
original with me, but I don't know if the originator wants to get
involved in this discussion at this time.
I won't explain how to implement this, since it's just straightforward
exploitation of data structures. However, I do want to mention some of
the things I've been thinking since I first heard this idea:
Unioned directories could be used in several ways to accomplish useful
things currently done via other approaches on conventional UNIX systems.
For example, one could set up his "command directory" to contain the
union of the desired real ones, replacing the PATH environment variable
and making the shell's job simpler (since it would just open a command
in a known place, rather than searching for it). As mentioned by Steve,
this could also be used in a Yost-like SCCS replacement. "cc" could
look in the user's "library directory" for all -l options. Many other
similar uses come to mind.
The order of precedence when two unioned directories contain entries
having the same name would be determined by the order in which the
directories were unioned. (In the PATH example, one would arrange for
the directory that would normally be leftmost in the PATH to be the
one with priority in the union.) There are uses for both union-with-
highest-priority and union-with-lowest-priority, so both should be
supported (I would do this at the system call level by using an extra
argument analogous to the mount() syscall's R/W flag). The originator
of this idea seemed to think that there was a natural choice to make
here, but I think that the "natural" choice depends on the intended use
and what is natural for setting up the equivalent of $PATH is not
necessarily natural for other uses, e.g. pushing and popping
environments. So far I've managed to identify the following union-
mount functions that I think are necessary:
Create a name with nothing associated with it (an empty union)
Append an object to the union (with low precedence of its members)
Prepend ditto (high precedence)
Remove one object from the union "tail" (lowest precedence object)
Remove one object from the "head" (highest precedence)
Destroy the name/union (may require that it be empty to succeed)
Optional but probably useful:
Remove all objects from the union (leaving an empty union)
Remove all objects but one from the head
Ditto from the tail
Report union tail object name (or other ID)
Ditto head object name
Ditto all unioned object names (this is difficult to design;
perhaps it should just report the nth object from the
head or tail.)
Many of these functions, perhaps all, could be combined into a single
interface. For example, head-relative might be a positive argument and
tail-relative negative.
That's enough for now. I'll let you guys think about this for a while.
I think it's a marvelous idea if it can be made to work (and I think
it can). However, the result would not be properly called "UNIX"..
Eduardo Krell
>
>Instead of allowing directories to be links to another directory,
>have an object with the superficial semantics of a directory but
>implementing a "copy-on-write" window onto a search path of other
>directories, perhaps chained to arbitrary depth.
I have already done exactly what you describe. We have an experimental
unix kernel with this facility added. It's very similar to the viewpathing
concept found in build and nmake (aka 4th generation make).
Basically, one can create a "continuation" directory, which will be searched
whenever a filename is being looked up and it's not found in the current
directory. That continuation directory can have more continuation directories
chained in a kind of linked list, and they are all searched in turn.
If the same file exists in 2 or more of these directories, only the first
one will ever be seen. File are always created in the first (original)
directory. Only file lookups follow these continuation pointers.
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrell
Lars Henrik Mathiesen
>Surely some other approach fully compatible with hard links could have been
>found.
Excuse me, but how are symbolic links *to files* different from hard links?
For that matter, it seems to me that you'd get exactly the same problems if
you used hard links to directories. The only way to distinguish between
hard and symbolic links is lstat(2) (and an occasional ELOOP), isn't it?
(From this point of view it is a *feature* of symbolic links that their modes
aren't ever used.)
The problem is that the use of symbolic links for directories is encouraged
(or at least not discouraged), which shows up the semantic problems much more.
But to solve the very real problem that csh(1) does not take symbolic links
into consideration when simplifying directory pathnames, I've written the
enclosed program for 4.3BSD. It is intended to be used with aliases as follows:
alias cd 'chdir `cdfix $cwd \!*`'
alias pushd 'pushd `pushdfix $cwd \!*`'
and includes special case code to supply the default arguments if none are
given (which is why it must have two links). It runs faster than my old
solution (which was to do a 'cd `pwd`' after each chdir or pushd).
--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark ..mcvax!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.
-------- cut here (cdfix.c AND pushdfix.c) ----------
/*
* This is the source for both cdfix AND pushdfix, which should be hard links
* to the same file. This goes for the source too.
*/
#include <stdio.h>
#ifdef DO_TILDE
#include <pwd.h>
#endif
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/param.h>
int errno;
char *errpath, *progname;
char usage[] = "Usage: %s old-dir-path change-dir-path\n";
char *getenv();
panic(file, syscall, error)
char *file, *syscall;
{
char buf[BUFSIZ];
sprintf(buf, "%s: %s: %s", progname, syscall, file);
if (error)
perror(buf, error);
else
fprintf(stderr, "%s\n", buf);
printf("%s\n", errpath);
exit(0);
}
#define LIM(x) (&(x)[MAXPATHLEN])
main(argc, argv)
char **argv;
{
static char head[MAXPATHLEN + 1], tail[MAXPATHLEN + 1];
register char *headend, *tailbeg, *cp;
struct stat stbuf;
int loop = 0;
#ifdef DOTILDE
char *name;
struct passwd *pw;
#endif
progname = argv[0];
errpath = argv[1];
if (argc != 3) {
if (argc != 2)
fprintf(stderr, usage, progname);
/*
* If this program is used to construct the argument
* to chdir or pushd in the csh, an empty argument is
* not equivalent to no argument; so we supply one that
* is equivalent. Assumes that two links are used, so
* that program name starts with 'p' for use with pushd.
*/
printf(*progname == 'p' ? "+1\n" : "~\n");
exit(0);
}
/*
* Check for the easy case.
* This also lets +n arguments alone for pushd.
*/
if (argv[2][0] != '.' && !index(argv[2], '/')) {
printf(argv[2]);
exit(0);
}
/*
* Set up head and tail, assuming that the old path is OK.
* Head contains a "canonical" path (no ., .. or superfluous /).
* Head is normally NOT null-terminated!
* Tail contains an non-canonical, absolute or relative path
* to append on to head while keeping head canonical.
*/
headend = head + strlen(argv[1]);
strcpy(head, argv[1]);
tailbeg = LIM(tail) - strlen(argv[2]);
strcpy(tailbeg, argv[2]);
#ifdef DOTILDE
/*
* Attempt to get a home directory if necessary.
* Normally this will be done by csh itself
*/
if (tailbeg[0] == '~') {
name = ++tailbeg;
while (*tailbeg && *tailbeg != '/')
tailbeg++;
while (*tailbeg == '/')
*tailbeg++ = '\0';
if (*name == '\0')
cp = getenv("HOME");
else
cp = (pw = getpwnam(name)) ? pw->pw_dir : NULL;
if (cp) {
strcpy(head, cp);
headend = head + strlen(head);
} else
panic(name - 1, "cannot substitute", 0);
}
#endif
while (tailbeg < LIM(tail)) {
/* Consistency check */
if (tailbeg[0] == '\0')
panic(head, "botch", 0);
if (tailbeg[0] == '/') {
/* Absolute pathname */
head[0] = '/';
headend = head + 1;
tailbeg++;
} else if (tailbeg[0] == '.' &&
(tailbeg[1] == '\0' || tailbeg[1] == '/'))
/* . - just skip it */
tailbeg++;
else if (tailbeg[0] == '.' && tailbeg[1] == '.' &&
(tailbeg[2] == '\0' || tailbeg[2] == '/')) {
/* .. */
if (headend == head + 1)
/* This was /.. - skip it */
tailbeg += 2;
else {
/* Make head into string, then back up over last element */
*headend = '\0';
while (headend > &head[1] && *--headend != '/')
/* void */ ;
/* See if head was a symbolic link */
if (lstat(head, &stbuf) != 0)
panic(head, "lstat", errno);
if ((stbuf.st_mode & S_IFMT) == S_IFLNK) {
/* Prepend the symbolic link to tail */
*--tailbeg = '/';
if ((tailbeg -= stbuf.st_size) < tail)
panic(head, "tail length exceeded", 0);
if (++loop > 20)
panic(head, "loop count exceeded", 0);
if (readlink(head, tailbeg, stbuf.st_size) != stbuf.st_size)
panic(head, "readlink", errno);
/* Go back and check for absolute vs. relative */
continue;
} else
/* Skip .. */
tailbeg += 2;
}
} else {
/* copy element to head */
if (headend > &head[1])
*headend++ = '/';
while (*tailbeg && *tailbeg != '/')
*headend++ = *tailbeg++;
if (headend > LIM(head))
panic(head, "path length exceeded", 0);
}
/* Remove redundant slashes */
while(*tailbeg == '/')
tailbeg++;
}
*headend = '\0';
printf("%s\n", head);
exit(0);
}
Tim Smith
current directory be a union of two directories, say A and B. There would
be two ways you could set up searches to work:
1: A first, then B
2: A first for create or write access, B first otherwise
I never got around to trying it, though.
--
Tim Smith, Knowledgian {sdcrdcf,seismo}!ism780c!tim
der Mouse
> (Isn't is about time we changed the subject line? :-)
Yes. So I did.
> Instead of allowing directories to be links to another directory,
> have an object with the superficial semantics of a directory but
> implementing a "copy-on-write" window onto a search path of other
> directories, perhaps chained to arbitrary depth.
[...]
> I have occasionally had to build a directory with a link to each file
> in another directory and then make a few small changes in the set of
> files: a deletion here and an addition there. Situations come up
> often where it would be nice to be able to set up a directory "just
> like" another "except for ...".
I have often come up against the problem of a directory containing a
bunch of symlinks to files in another directory, just as you described.
The usual case is a source directory on our Suns, where I want all or
most of the source files (.c and .h) to be symlinks to a parallel
directory on our VAX, but the .o and executables to be local. What I
was considering doing about it, though, was to implement a "generic"
symlink. This would be an object which could contain files just as a
directory does, but when a lookup is done, if the name being looked for
is not in the generic-symlink directory, the kernel follows the symlink
and looks there.
This is a pipe dream at the moment. In particular, I see problems with
opening a file for write (assuming it doesn't exist in the
generic-symlink directory). Should it follow the link or not? In the
usage I mentioned above, it depends: for a source file, it should
follow the link; for a .o file, it should create it locally. Perhaps
it should depend on whether it's been opened for reading previously.
Perhaps the semantics are wrong: perhaps opening a file for read and
finding it in the symlinked-to directory should create a local symlink
for later use. Perhaps lots of things. Any ideas?
der Mouse
(mo...@mcgill-vision.uucp)
Steve Nuchia
> [...] directory does, but when a lookup is done, if the name being looked for
> is not in the generic-symlink directory, the kernel follows the symlink
> and looks there.
>
> This is a pipe dream at the moment. In particular, I see problems with
> opening a file for write (assuming it doesn't exist in the
> generic-symlink directory). Should it follow the link or not? In the
> usage I mentioned above, it depends: for a source file, it should
> follow the link; for a .o file, it should create it locally.
Well, the thought that leapt into my mind on reading this was
"why not use a program as the generic-symlink object". It would
act as a filter for nami; this gets into the lightweight process
thread and probably a few others.
But this is exactly the idea I'm working on in my research, ie an
"object oriented" operating system, and as has been pointed out already
it would be stretching things to call such a system "UNIX".
But we are all entitled to our pipe dreams, aren't we?
Steve Nuchia 334 1204 (hire me)
{housun,{soma,academ}!uhnix1}!nuchat!steve