Sending Tcsh to packages/ports ...

[Polytropon]

On Sat, 30 Mar 2019 09:45:38 +0530, Mayuresh Kathe wrote:
> On 2019-03-30 08:28 AM, Polytropon wrote:
> > On Sat, 30 Mar 2019 08:13:33 +0530, Mayuresh Kathe wrote:
> >> On 2019-03-30 08:03 AM, Polytropon wrote:
> >> > On Fri, 29 Mar 2019 19:08:16 +0530, Mayuresh Kathe wrote:
> >> >> On 2019-03-29 04:59 PM, Daniel Feenberg wrote:
> >> >> > On Fri, 29 Mar 2019, Mayuresh Kathe wrote:
> >> >> >
> >> >> >> 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.
> >> >> >
> >> >> > 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.
> >> >>
> >> >> What if you had access to your preferred tools via packages/ports?
> >> >
> >> > 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.
> >> 
> >> 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?
> > 
> > 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.
> > 
> > I hardly know people who use sh for more than "csh" (to start
> > csh).
> > 
> > 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.
> > 
> > The scripting shell _must_ always be accessible, and FreeBSD
> > provides an interactive shell which also always works.
> > 
> > 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.
> > 
> > Sidenote:
> > 
> > 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. :-)
> 
> 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.

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 
> scripting system and the shell is also quite interactive.

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.
> > 
> > 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?
> 
> 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 
> re-type my command chain effortlessly.

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.






-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...