Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 Mar 2019 11:36:27 +0000
From:      Carmel NY <carmel_ny@outlook.com>
To:        FreeBSD <freebsd-questions@freebsd.org>
Subject:   Re: Sending Tcsh to packages/ports ...
Message-ID:  <MWHPR04MB0495C03B1790D596A83EEB9D805B0@MWHPR04MB0495.namprd04.prod.outlook.com>
In-Reply-To: <20190330054824.541c1bff.freebsd@edvax.de>
References:  <64780f09d4251b9641e3bca39000ae2d@kathe.in> <alpine.BSF.2.21.9999.1903290725040.71125@mail2.nber.org> <869a55f05dde045b1947f53ce3c5851f@kathe.in> <20190330033342.e5fc3373.freebsd@edvax.de> <2aee9abe70cc944b634751e5df0b375e@kathe.in> <20190330035857.86508c3a.freebsd@edvax.de> <e9cf8829e9595966a32aab182906e8a5@kathe.in> <20190330054824.541c1bff.freebsd@edvax.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 30 Mar 2019 05:48:24 +0100, Polytropon stated:

>On Sat, 30 Mar 2019 09:45:38 +0530, Mayuresh Kathe wrote:
>> On 2019-03-30 08:28 AM, Polytropon wrote: =20
>> > On Sat, 30 Mar 2019 08:13:33 +0530, Mayuresh Kathe wrote: =20
>> >> On 2019-03-30 08:03 AM, Polytropon wrote: =20
>> >> > On Fri, 29 Mar 2019 19:08:16 +0530, Mayuresh Kathe wrote: =20
>> >> >> On 2019-03-29 04:59 PM, Daniel Feenberg wrote: =20
>> >> >> > On Fri, 29 Mar 2019, Mayuresh Kathe wrote:
>> >> >> > =20
>> >> >> >> Since Tcsh is usually imported, why not send it to
>> >> >> >> packages/ports collection?
>> >> >> >> I agree that "csh" is an historically important artifact,
>> >> >> >> but do we need to still rely on that?
>> >> >> >> I have been using "csh" ever since I started using FreeBSD,
>> >> >> >> liked it, but it doesn't feel light like plain old "sh" nor
>> >> >> >> is as feature-full as "bash". To top that, the installer
>> >> >> >> asks me to choose between "csh" and "tcsh" in-spite of
>> >> >> >> being the same binary. =20
>> >> >> >
>> >> >> > ed and csh are important for those that use them. I use
>> >> >> > both, not always, but enough to see the importance of
>> >> >> > keeping them in the OS. There is a fallacious style of
>> >> >> > argument that decodes to "If a is better than b, then b is
>> >> >> > no good and it is a sign of bad character to use b". There
>> >> >> > are many cases where the transition costs of moving to
>> >> >> > different dependencies will be significant, especially for
>> >> >> > less well informed users. =20
>> >> >>
>> >> >> What if you had access to your preferred tools via
>> >> >> packages/ports? =20
>> >> >
>> >> > The core problem is an educated consensus about what should
>> >> > be the default content of the OS. Access to ports or packages
>> >> > usually implies that you have (a) the installation media, or
>> >> > (b) Internet access. In cases where this does not apply, for
>> >> > reasons like "didn't think about that", "our Internet doesn't
>> >> > work", "Security! Security! Security!" and more, you should
>> >> > definitely _not_ be left with an OS that doesn't have a usable
>> >> > interactive shell or an editor. The mentality of "you can always
>> >> > install it afterwards" should not be applied to basic OS tools
>> >> > and demands. =20
>> >>=20
>> >> But the basic operating system tools would include the Bourne
>> >> Shell (sh), or as you'd stated previously, in the case of
>> >> FreeBSD, the Almquist Shell (ash). Isn't "ash" interactive enough
>> >> for most people? =20
>> >=20
>> > No. This shell is traditionally a scripting shell. The only
>> > occassion where you would use it is after a severe system
>> > crash, and even from that point, you'd probably just start
>> > the C shell for better interactive features.
>> >=20
>> > I hardly know people who use sh for more than "csh" (to start
>> > csh).
>> >=20
>> > On most Linux systems, there is one shell both for scripting
>> > and for interactive use, and it's usually /bin/bash. FreeBSD
>> > differentiates between scripting use, where the POSIX-compliant
>> > sh is used, and interactive use, where the C shell is the
>> > traditional shell, but a user can of course install and use
>> > a different shell.
>> >=20
>> > The scripting shell _must_ always be accessible, and FreeBSD
>> > provides an interactive shell which also always works.
>> >=20
>> > It's important to understand that a custom user shell might not
>> > be available in single-user mode, in a condition where the system
>> > can only operate in a very limited way. That's why it's still
>> > valid to say you should not change root's interactive shell
>> > to something like /usr/local/bin/bash which might cause trouble
>> > logging in when /usr or /usr/local cannot be accessed. That's
>> > what the toor user is intended for.
>> >=20
>> > Sidenote:
>> >=20
>> > Some historical UNIX systems actually used the C shell for
>> > scripting to bring the system up into multi-user mode. Luckily,
>> > this is not done anymore as scripting (!) in csh is terrible
>> > and confusing. :-) =20
>>=20
>> Actually, looking it at it from a different angle, "csh" scripting
>> would be ideal, because then one would need to know only one _style_
>> of programming, the "c" style. =20
>
>The core problem with the C shell is that it has several
>implementation flaws. There is a document by  Tom Christiansen,
>titled "Csh Programming Considered Harmful", summarized:
>
>	The csh is a tool utterly inadequate for programming,
>	and its use for such purposes should be strictly banned.
>
>You can find the full text here:
>
>	https://www-uxsup.csx.cam.ac.uk/misc/csh.html
>
>Personally, I once (!) wrote a C shell script, and this
>particular script is still working, but I would _never_ again
>do something like this. :-)
>
>That being said, sh (Bourne shell) has become the de-facto
>standard for scripting, and with the POSIX compliance, it
>allows you to write scripts that can be run on any OS that
>provides a POSIX-compliant sh implementation, without needing
>to test for the OS name, the shell version, or a specific
>feature.
>
>
>
>> That's what I love about "Plan 9", it's shell "rc" uses a "c" style=20
>> scripting system and the shell is also quite interactive. =20
>
>Even better: rc exposes the "everything is a file" metaphor
>of the OS in a convenient way, so many things can be done
>with tools that operate on files, even if that file represents
>a network connection or a remote audio device.
>
>
>
>> >> At
>> >> least I have found it good enough for my day-to-day use. =20
>> >=20
>> > You are actually using /bin/sh interactively? Not that it's
>> > impossible, but... well... why use sh when the OS provides you
>> > csh whose interactive features are much more advanced and
>> > customizable? =20
>>=20
>> I don't know why, but I find it peaceful to use "/bin/sh".
>> Probably because it's so small, so ancient and so well documented.
>> Plus, I touch-type at a very high speed, so any mistakes, and I can=20
>> re-type my command chain effortlessly. =20
>
>Same here, but I'd say that about the C shell, with only a
>few configuration tweaks to make things appealing, instead
>of the work I would have to invest to make bash behave in
>a way comparable to certain csh defaults. :-)
>
>By the way, the zsh is often considered the most advanced
>shell, as it incorporates all the advantages of existing shells
>without also inheriting their annoying behaviour. It's well
>documented and highly customizable, but works very good even
>with only the defaults.

There is a fairly comprehensive comparisons of the various shells
available on wiki.

https://en.wikipedia.org/wiki/Comparison_of_command_shells

For the record, the first thing I do when doing a fresh install of
FreBSD is to install "bash" and make it the default shell. Its
documentation is some of the best I've seen and the bash forums are
always available to assist you.

--=20
Carmel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MWHPR04MB0495C03B1790D596A83EEB9D805B0>