linq

[ghe <ghe@slsware.net>]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, February 26, 2020 9:10 AM, David Wright
<deblis@lionunicorn.co.uk> wrote:

> > Looks to me like it means 'link <here> to <here>'
>
> Indeed. This means that an old script which tries to run
> /usr/bin/X11/foo will succeed in running /usr/bin/foo,
> which is where foo will have been placed.

I looked around and couldn't find the file that was linked in to bin.
But it must be somewhere since startx still worked.

> If ls X11 worked, then your working directory is presumably
> /usr/bin or /usr/bin/X11…, so you're doing this as root, and are
> writing the output to a file in /usr/bin, so the file will include
> an entry for X11.a.

Does indeed.

> Likewise, the second command will contain
> entries for X11.a and X11.b. Is that the "garbage" showing in diff?

Yes. A random looking number and one of the X11s.

> Hence the importance, stressed by others, of showing your commands
> (with their prompts) as well as the actual output.

Gotcha. I thought I'd included enough for a competent *nix guru to
understand what was going on.

> I have no idea whether your system has anyreliance on the symlink.
> It just depends on what's installed, and of what vintage.

Buster. Should have mentioned that.

> If you go back in time, the X11 system was segregated in its own
> directories under such names as X11R5, X11R6 and X386, so its
> binaries would be in, say, /usr/X11R6/bin and its libraries …
> You get the drift.
>
> As X11 evolved, symlinks like /usr/bin/X11 → /usr/X11R6/bin were
> made so that scripts could use the newer names. Now those scripts
> are out-of-date as everything is in /usr/bin, so the link allows
> them still to work. Similar skullduggery was going on under /etc,
> /usr/lib and /usr/include etc.

> On the down side, it made running two different versions of X, say
> X11R6 and XFree86, on the same system next to impossible.
>
> You may be running a system where even /bin and /sbin have ceased
> to exist as directories, and are merely symlinks to /usr/bin and
> /usr/sbin. Evolution? Tidying up? …

No. In Buster, /usr/(s)bin are still dirs on all the Linux computers
around here (2 AMD64 Busters and a Raspbian Buster):

root@sbox:~# ls -lh /usr | egrep bin
drwxr-xr-x   3 root root  60K Feb 24 16:48 bin
drwxr-xr-x   2 root root  20K Feb 24 16:46 sbin

root@gobook3:~# ls -lh /usr | egrep bin
drwxr-xr-x   2 root root  64K Feb 24 16:54 bin
drwxr-xr-x   2 root root  16K Feb 24 16:52 sbin

root@srv:~# ls -lh /usr | egrep bin
drwxr-xr-x   2 root root  36K Feb 18 09:52 bin
drwxr-xr-x   2 root root  12K Feb 18 09:52 sbin

Thanks for the explanation.

Both evolution and BandAids on BandAids seems to be the answer. Tidying
up, IMHO, bears some consideration. I've spent significant time cleaning
up my own code when things changed for no reason (none to me, anyway).

I haven't dealt anything as big or old as a kernel/disk layout, though,
so maybe the eleventy million links in Debian are justified there...

-- 
Glenn English