Date: Wed, 28 Feb 2001 13:03:11 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: "David O'Brien" <obrien@FreeBSD.org> Cc: Christian Weisgerber <naddy@mips.inka.de>, Steve Price <steve@FreeBSD.org>, freebsd-ports@FreeBSD.org, Maxim Sobolev <sobomax@FreeBSD.org> Subject: Re: ksh93 Message-ID: <20010228130311.A32596@hamlet.nectar.com> In-Reply-To: <20010228092818.C92203@dragon.nuxi.com>; from obrien@FreeBSD.org on Wed, Feb 28, 2001 at 09:28:19AM -0800 References: <3A9CF86E.18C36ED0@FreeBSD.org> <20010228091630.B92203@dragon.nuxi.com> <20010228112329.A9192@hamlet.nectar.com> <20010228093214.D92203@dragon.nuxi.com> <200102260514.f1Q5EHJ96328@freefall.freebsd.org> <20010226215311.A44937@spawn.nectar.com> <20010227154226.A36915@kemoauc.mips.inka.de> <20010227162104.A7892@dragon.nuxi.com> <20010228065758.A29047@hamlet.nectar.com> <20010228092818.C92203@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't want to spend a lot of time arguing this -- I don't feel
strongly either way. Nevertheless I'll go one more round for fun,
and because I do truly think that these shells should be dynamic
for most users.
On Wed, Feb 28, 2001 at 09:28:19AM -0800, David O'Brien wrote:
> On Wed, Feb 28, 2001 at 06:57:58AM -0600, Jacques A. Vidrine wrote:
> > What do you suggest? That all shells be linked and installed
> > statically? Is there something that makes shells special,
>
> Duh! Please think for a moment. Broken shell means one cannot login to
> fix library problems. For those of us that sufficiently hate the stock
> shells, it certainly is nice to be able to use their shell of preference.
> Also, what about remote machines, or machines whose access to their
> consoles are inconvient? One must login in as a mortal before su'ing.
> The reasons the base system shells are static are the same reasons shells
> in ports should be static.
I don't agree. From my perspective, our use of /bin/sh is a different
beast from ports shells. `sh' must be static for several reasons:
= It is used very early in the boot process
= It is invoked a lot and often by all kinds of processes, but
especially by make
= There _must_ exist a `fall-back' shell for the kinds of
situations that you describe -- it might as well be sh
When your system is hosed (libc.so trashed or /usr unmountable), then
you use e.g. /bin/sh and /bin/ed instead of ksh/bash/zsh or vi.
Making ports/shells/foosh static isn't enough for these situations --
it probably has to be installed in /bin also.
As for remote machines, telnetd and login are going to be unavailable
in this situation, too.
> > or do you want all ports built static by default?
>
> Uh, where did I use suffient generalizations in my response to make you
> think I was talking about the entire ports collection?? This discussion
> is about ksh and shells.
I'm sorry, that was an assinine way of emphasizing that I wondered
what made you think shells are so different from other applications.
> > I would like it if all the shells in ports/shells were linked dynamic
> > by default, but had knobs for getting static versions.
>
> You aren't backing this up. I have given reasons for static versions by
> default. Do you just hate static binaries, or is there a good reason for
> wanting the ports shells dynamic? Please note that static shells
> typically execute faster.
No, I don't `hate static binaries'. I already stated in this thread
that I personally keep a static version of my favorite shell in /bin
(as well as the dynamic version in ${PREFIX}/bin).
I think the ports shells should be installed dynamic because:
= Some have functionality that require dynamic linking (ksh, bash,
zsh, possibly others).
= If libc is replaced, users can benefit from that (as with any
application).
> > Then one can have WANT_STATIC in /etc/make.conf (man, we really need a
> > separate make.conf-type file just for ports).
>
> Why not make the knob "WANT_DYNAMIC_SHELLS"??
Because I believe that the average user benefits from a dynamically
linked shell. Other users know enough about what they want to do a
static install.
Thinking more on it and about how I usually install my shells, my
personal convenience would be best served with something like a
SHELL_LINKING knob that could be multivalued. On my system, I would
want SHELL_LINKING="static dynamic". I'd want the static version
installed in /bin. But whatever, I can do it myself, which is what
I do now :-)
> > Personally I like to keep static versions of my favorite shell(s)
> > installed in /bin.
>
> If I have to do this:
>
> cd /usr/ports/shells/foo && make WANT_STATIC=1 PREFIX=/ install
>
> I'm starting to loose the connivance of the Ports Collection.
> (plus I'm also polluting the base system with all the extra files some of
> the ports have that I really don't care about)
I don't quite follow. I don't think any of the shells install in /bin
by default, and some of them already link dynamic unless you twiddle
some knob. I know you think this is a bug. I think that the fact
that the others link static is a bug :-)
> And I quite often use ``pkg_add -r'' anyway.
>
> > However, ksh93 supports dynamic loading of commands.
>
> Ok, for ksh93 specifically there may be a reason. But one can still use
> static libs and use dl*().
Such a binary would have none of the advantages of a static executable
(runnable without /usr, more memory-efficient).
> > That doesn't mean that static linking is never appropriate, I just
> > think that it shouldn't be the default for most people.
>
> Then why not make /bin/*sh dynamic and put libc.so in /lib ?
I assume this was a rhetorical question?
On Wed, Feb 28, 2001 at 09:32:14AM -0800, David O'Brien wrote:
> On Wed, Feb 28, 2001 at 11:23:29AM -0600, Jacques A. Vidrine wrote:
> > Well, ld.so could still break, and anyway you'd lose the ability to
> > use a replacement libc. I don't think this middle ground would be all
> > that useful.
>
> Other than for SOCKS, since ksh93 has network functions, why would you
> need to use a replacement libc? 97% of our users will never want to use
> a replacement libc. However, disk corruption and other system problems
> _DO_ occur.
By `replacement libc' I was thinking of the result of `make world'.
I'm pretty sure that more than 3% of our users are interested in libc
fixes.
> I will claim that the number of users wanting to use dynamic modules with
> ksh is much small than those that won't. So why not put make the power
> uses have to use a special knob, vs. the majority?
You are claiming that the majority of interactive shell users want
their shell statically installed, apparently based on the fact that
they could then use said shell to recover their system when libc gets
corrupted. But I don't think the majority of our users are capable of
repairing a system in this fashion -- and those who can, know enough
to decide to install a shell statically, or not.
> > or "Why doesn't ~user work where said user is in LDAP?"
>
> Uh, then if the user's shell is /bin/tcsh which is static, why won't this
> be a problem???
It will be, and that's too bad. But tcsh is kind of a special case --
there seems to be no technical reason for it to be static or in the
base system. It is there largely due to tradition (and I would not be
happy if it were removed, even though I don't csh).
> > > Which shell uses dl*()?? Why is this needed, and why complicate things.
> >
> > ksh93. See the man page under `builtin'.
>
> Then please don't object to "plain" shells in ports being dynamically
> linked.
I still think it would be better that they were not static, but I'm
not willing to fight over it. I also think that it is somewhat silly
to have them static, but not in the root filesystem.
It would be nice if we built foosh-1.0 and foosh-static-1.0 packages.
Cheers,
--
Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010228130311.A32596>