* Helmut Grohne <hel...@subdivi.de> [2021-06-28 14:46]: > On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote: > > It also means that on /usr-merged systems e.g. /bin/screen is not a > > "valid" shell, but /usr/bin/screen is (even though they are the same > > file), which may be fine in practice but seems counter-intuitive to > > me. > > Valid concern. Do you think that I should include machinery specifically > for handling the /usr merge in update-shells? Automatically adding > /bin/screen on /usr-merged systems where shells.d contains > /usr/bin/screen is feasible. I see little value though as > /usr/bin/screen has always worked on Debian and why would anyone use > /bin/screen now?
Few people would probably *change* /usr/bin/screen to /bin/screen. But some people -- maybe new users -- might not know that /usr/bin/screen is more "traditional"/"canonical" than /bin/screen. I myself might be tempted to use /bin/screen when editing a file (and knowing that /bin = /usr/bin on the relevant system(s)) since it's shorter :) Also: there's no /usr/bin/sh. Now *I* would always type /bin/sh, but setting my shell to $(which sh) would currently result in an invalid shell: |$ which sh |/usr/bin/sh |$ grep $(which sh) /etc/shells || echo OOPS |OOPS Personally, I'd prefer some consistency at least. Either always provide both paths on merged /usr systems, or only provide the "canonical" path on all systems. Not some shells with both entries and some with only one. > #699177 I didn't know about that bug. Thanks. - Felix