Re: /bin/pwd

Sam wrote:
> > * Daniel Jour <[email protected]> [2016-08-28 23:55:18 +0200]:
> >
> >> pwd is also a shell built-in, so full path is necessary.
> >
> > Hm, I understand why pwd may give (in case of symbolic links) a
> > different result as a non-builtin pwd. Why do we need the physical
> > (not logical, i.e. without the symlinks) path, though?
> >
> > As for /bin/pwd ... this is a bad idea. /bin (the directory) is about
> > to die (ok, that's a bit drastic, I'm reffering to the "usr merge"
> > here), and there may be more than one pwd on a single system (this is
> > the main reason for this change, because it directly affects me. This
> > could be fixed downstream by the currently few affected distributions,
> > too. But in the future this might affect every linux distribution that
> > uses systemd.)
> 
> this is news to me.
> "/bin/cp" going away will break so much stuff that I doubt that anyone
> will seriously contemplate this.
> 
> any unix experts here?

Differences between /bin/<prog> and <prog> in general:

  * You can be sure that /bin/<prog> exists; you don't need to handle
    the case that PATH has been set in such a way that <prog> is not found.

  * PATH is under user control. If you use <prog> you need to handle
    the case that <prog> is not executable, a dangling link, or it could
    be slowed down on an NFS volume etc.

Differences between /bin/pwd and pwd in particular:

  * pwd being a shell built-in, it takes care not to canonicalize the
    directory name. If we want to canonicalize the directory name, e.g.
    to test whether two directories are equal
      A_abs=`cd "$A" && /bin/pwd`
      B_abs=`cd "$B" && /bin/pwd`
      test "$A_abs" = "$B_abs"
    we can only use /bin/pwd.

The only good argument against /bin/<prog> that I can see is that some
modern distros, like GNU GuixSD, construct PATH based on symbolic links.
But I would expect them to have a mechanism to simulate a /bin directory
in some way.

Bruno


------------------------------------------------------------------------------
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel