Re: What are desired semantics for /etc/shells?
* Helmut Grohne <helmut@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
Reply to: