Re: status update

> 15613::::Daniel Jour 2016-04-30 clisp-link.in: Replace /bin/pwd with calls to pwd (for NixOS)
> 15617::::Daniel Jour 2016-05-18 Don't call cat by absolute path

> > 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?

That's just part of the issue.
For example, on OpenBSD, using ksh(1):

  $ cd /tmp
  $ mkdir foo
  $ ln -s foo bar
  $ cd bar
  $ pwd
  /tmp/bar
  $ /bin/pwd
  /tmp/foo

More importantly, /bin/pwd is a standardized UNIX binary,
guaranteed to exist, with behaviour defined by POSIX
- as opposed to "pwd", which can be a shell builtin
(of whichever shell the user is running),
or anything named "pwd" that happens to be in $PATH.

So make your mind about whether you want the symlinks resolved or not,
and call either "/bin/pwd -P" or "/bin/pwd -L".
(Because the default behaviour without options can also differ.)
http://man.openbsd.org/OpenBSD-current/man1/pwd.1

> As for /bin/pwd ... this is a bad idea.
> /bin (the directory) is about to die

Stop smoking that shit.

/bin has been around for decades and will continue to be,
whatever any linux distro du jour gets to its head.

> (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

So use the standard one, obviously.

> (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.)

UNIX is not this or that "affected Linux distribution".
http://man.openbsd.org/OpenBSD-current/man7/hier.7

> Same goes for /bin/cat

Exactly.

> There might be more than one cat, and all of
> them might be in a different location than /bin.

Except /bin/cat will always be there, with POSIX-defined behaviour.
So use that, obviously.

> Thus it's better to let the user (or the user's configured
> environment) choose which cat to use.

Quite the contrary: this is the reason to use the standard one.

> Perhaps we could use (if it's still needed then) an autoconf macro to
> determine the "correct" cat and pwd? (Using $CAT and $PWD then, so the
> user could change these.)

Yeah right. Let the user rewrite PWD.


On Aug 29 19:32:28, [email protected] wrote:
> I think what Daniel is suggesting here goes farther than the current goals
> of the usr-move camp (see [1] and [2]). Traditionally, /bin and /usr (thus /usr/bin)
> could live on different partitions and be mounted at different points in time. I
> believe defenders of the usr-move idea will argue that there’s no good use case
> for that anymore,

On OpenBSD, for example, the programs in /bin are statically compiled,
and therefore do not depend the libraries or the linker.
That's why you can use them to e.g. repair your system in single-user mode,
with /usr/* botched. Or use them in scripts without further assumptions.

> so that /usr can just be assumed to be available whenever /bin
> is assumed to be available.

Again, that's not the issue here.

> That does not mean that /bin/cp and the like go the
> way of the dodo but rather that they might be symlinks to /usr/bin/cp, so that as
> a package maintainer you no longer need to spend time thinking about what has
> to go in /bin and what can go in /usr/bin instead.

How much time do you need to spend thinking about the following?

$ ldd /bin/ls
/bin/ls:
  Start            End              Type Open Ref GrpRef Name
  000001301d32b000 000001301d778000 dlib 1    0   0      /bin/ls

$ ldd /usr/bin/diff
/usr/bin/diff:
  Start            End              Type Open Ref GrpRef Name
  00001a3559f00000 00001a355a309000 exe  1    0   0      /usr/bin/diff
  00001a3773834000 00001a3773cfd000 rlib 0    1   0      /usr/lib/libc.so.88.0
  00001a3760300000 00001a3760300000 rtld 0    1   0      /usr/libexec/ld.so


On Aug 30 09:17:33, [email protected] wrote:
> Bruno Haible <[email protected]> writes:
> > 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.
> 
> counterexample:
> 
> $ ls -al /bin
> total 8
> drwxr-xr-x   2 root           root     4096 2016-08-25 09:44 .
> drwxr-xr-x  17 root           root     4096 2016-05-29 00:28 ..
> lrwxrwxrwx   1 root           root       63 2016-08-25 09:44 sh -> /nix/store/9zv8ph14qa9x685ig6agxy9yzxcapfar-bash-4.3-p42/bin/sh
> $

That's not a counterexample: /bin/sh exists, as it always should;
but depending on PATH, "sh" might not be found.

> Any dependency on external programs comes with many assumptions and no
> guaranties.

Except the standardized /bin/pwd etc,
which is precisely the reason to use those, and not some others.

> For example, using /bin/<prog> harcodes the assumption
> about FHS, among others.

Yes. Much like using printf(3) hardcodes
the assumption that you have a standard C library.

> > 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.
> 
> Yes.  They don't simulate the /bin directory.  They patch away the
> hardcoded paths and construct the environment in such a way, that the
> program uses the right dependencies.  Or, they replace the hardcoded
> path with the correct path of the dependency.
> 
> So from the point of those modern distros, I think it is slightly better
> not to hardcode the FHS assumption so that they do not have to patch the
> sources.

Something small in me dies every time I see a _language_interpreter_
being considered "from the point of modern distros".

	Jan


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