> Not many young people know Perl or Tcl

There are more young people who know Perl or Tcl or Lisp than know Crush. I've never understood this reasoning - "Hardly anyone knows X. Let's replace it with something nobody knows." At most, you're making an argument about a lack of sunk cost.

> May be some "new" shell will catch up and tomorrow's "all" programs will be compatible with that shell

Think of it like transitioning to life in a wheelchair. You can't "catch up" with your house - it just wasn't designed for wheelchair use. Renovating all the narrow corridors, random steps, tight angles and vertical reaches probably costs more than rebuilding.

In this comparison, the mobility mode is your shell.

"Hardly anyone knows X. Let's replace it with something nobody knows."

Because there's a value proposition. Just like TCL, Perl, and Lisp had value propositions over other available languages. It's fine if you don't see the value proposition in Crush but progress sometimes forces us to learn new things instead of sticking with what we have.

Crush has been around < 1 year. Perl has been around for 32. Of course more people know Perl.

If I’m being honest, you’re not adding anything constructive at all here - it seems you’re in a competition with yourself as to how much you can degrade Crush for whatever reason.

You act like it’s a choice between Crush and Perl. People don’t have to learn Crush. People don’t have to learn Perl. Will picking between the two have any substantial effect on one’s career outcomes these days? Probably not, as candidates will have already learned the important languages for getting a job anyway.

If I'm being honest, I have no idea where you got the belief that either I'm some big Perl partisan or that I have something against Crush, or why you're getting so personal.

But it is cute to couch it in a complaint about not being constructive; points for shamelessness.

>> Hardly anyone knows X. Let's replace it with something nobody knows

By that logic no one should make anything new to replace the incumbent.

In case of Perl, PHP came and it replaced Perl as mainstream web development language.

In sysadmin stuff where Perl used to be mainstream, now significant chunk is taken away by Python.

These days JavaScript appeals to younger people more. Times change and with it the tools people use also change.

There is no guarantee that any new project will succeed but you won't know unless you try.

The original point was "why would I learn a new thing, when I already know something which works". The response "some people don't have something they already know" is valid.

You're really bringing up a separate point which is "should we be reinventing the wheel?", I think that's a fair point, but it's not a response to the original commentator.

It only took Zsh 29 years (initial release year: 1990, adoption in Mac OS: 2019) to become the default shell on one of the major nixes, while being POSIX compatible and having just an extension layer on top.

I wouldn't hold my breath for something else to replace sh/bash as the default shell on the major nixes within this century. Pessimist? More like realist :-)

That wasn’t even driven by zsh’s actual benefits, but by the fact that bash changed to GPL3. If it had continued on GPL2 we’d 100% still have bash as a default.

And the fact Apple doesn't like GPLv3.

Most other major UNIXes, before of BSD/Linux takeover weren't on sh, rather tsch and ksh.

Many young people don't know history, science, other languages, or even the grammar of their native language. That is why we teach.

The "ecosystem" of programming languages is healthy. There are many options, some to master, some to consider. But not knowing how to use a tool -- especially a widely-used and powerful tool -- is no badge of honour or discernment.

> That is why we teach.

but what if people don't know how to learn?

instead of getting wrapped up in all of this 'knowledge preservation' nonsense, shouldn't we just mimic what they are already doing and assume it to be better, because the activity occurs in a year number that is higher than the previous behavior pattern?

now that would be real progress.

or, not.

Sarcasm duly noted. (o;

Societal results sadly noted.

> Not many young people know Perl or Tcl (or even lisp for that matter).

I don't know perl and I'm not young, but I do understand and appreciate the role perl -e plays as an extension of bash. When I run into an issue where I need more than bash, but less than python, I'll search around SO for a perl -e command for what I need.

This is often how people decide to learn a tool: they have a problem for which it is the best solution. They get some exposure to the capability and slowly expand on their knowledge.

I think that means you're using SO as a tool..?

Don't most of us? That doesn't mean he's not using Perl as well.

I explicitly included zsh. The point is not the language of the shell itself; that has never been the point. The point is that zsh interoperates with the other programs on your system in a way that crush doesn't and can't.

> a way that crush doesn't and can't

What do you mean by can't? If it misses some mode of interaction, that can be always added.

Consistent behavior when piping through all commands. A lack of modes of operation to consider. Simplicity.

Simplicity exists on more than a single dimension. Choosing one column from "ls" output for example is not simple, bordering on impossible using the consistent behaviour of standard pipes.

Sometimes the inconsistent solution will be simpler by moving the complexity to the choice of the mode of interaction. Sometimes not.

You are correct. It is all about how you think about things.

"ls" lists files. Sure. Simple interactive command. But, thinking about this, "echo " also lists files. "ls" provides information about files. Sure. Simple interactive command. But, "stat" specifically provides information.

So, I would reach for

stat --format "%n %a"

To get name and octal permissions. You are correct, and wrong at the same time. Easy enough to accomplish -- but using * instead of ls. Note that the "space in filename" becomes the big issue (use %N in stat format).

So your conclusion is 100% correct. Thank you for your post and insight

> Choosing one column from "ls" output for example is not simple, bordering on impossible using the consistent behaviour of standard pipes.

  ls -l | awk '{print $3}'
  ls -l | cut -f 3 -d ' '

Maybe a shell is the wrong tool for that job, and hiding the modes that the language is operating in complicates things.

Nor do they know that before bash takeover of the UNIX world via BSD and GNU/Linux clones, it was just another shell among many others, with tsch and ksh also having a place on the table.

when he says Perl or Tcl I think he means general purpose languages. It doesn't have to be Perl, or Lisp or Tcl, those are examples.