Sending Tcsh to packages/ports ...

[Mayuresh Kathe]

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.
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.

>> 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.

~Mayuresh