> On those echo that support options, there's generally no support of a -- to mark the end of options (zsh and possibly others support - for that though), so for instance, it's difficult to output "-n" in many shells.
It's good to know (while the key takeaway lesson is "use printf"):
God, I hate posix. The UNIX Haters were right about a lot of things, but none more so than the utter brain-damage of the shell's argument parsing unfeature.
> but how would you have a system that's anywhere near this powerful without them?
The arcane UX that POSIX gives us has no connection or correlation whatsoever with the power of the system.
For instance, an enhanced IPython shell alone would be 10x better than bash. You wouldn't loose any power in this manner.
In fact, I think it would be good if thought about or reflected on what exactly "power" is. IMO, it's programmability / script-ability. And Python (again, imo) is a much better language than bash -- hence a shell based on it would deliver a far better UX than bash ever would.
And yet... serious Python hackers aren't using an enhanced IPython shell. Basically no one is using anything but bash, and even the contrarians aren't going any farther than zsh. This despite the fact that very few people who use these shells ever both to write scripts in them. Certainly people could learn "better" interactive shells. Yet they don't.
Clearly the Bourne shell and its descendents must have been doing something right.
Would you concede Perl to be a better language than Bash? If so, have a look at 'psh'. It's a Perl shell that nobody uses.
The language has nothing to do with why someone picks a shell. They just get used to something, it becomes good enough, and they get on with life. We don't need the most powerful, the most flexible, the most efficient thing. We just need something simple that works. Bash works, so stop nit-picking.
The ubiquity of POSIX sh has nothing to do with technical worth and everything to do with network effects. Should people stop being irritated by bad software because it works, for some definition of the term works? I would hope not.
I've seen really old scripts that use awk oneliners doing a printf (like echo | awk '{ printf ...) cause (and I have to guess here) it was not built in to /bin/sh and there was no /usr/bin/printf command either!
As a former Sun consultant, the most common question I had to fend from customers during those 10 years was the lack of a printf. Fortunately, Odersky has much better taste & Scala shipped with a printf on day 1 in Predef.scala, via Console(https://github.com/scala/scala/blob/v2.10.1/src/library/scal... )
18 comments
[ 5.8 ms ] story [ 48.6 ms ] threadIt's good to know (while the key takeaway lesson is "use printf"):
echo -n - ; echo n
The printf command means "print, formatted," where "format" refers to "positional parameters," and this functionality is not present in echo.
Signed, a Unix aficionado.
http://www.gigamonkeys.com/book/a-few-format-recipes.html
The arcane UX that POSIX gives us has no connection or correlation whatsoever with the power of the system.
For instance, an enhanced IPython shell alone would be 10x better than bash. You wouldn't loose any power in this manner.
In fact, I think it would be good if thought about or reflected on what exactly "power" is. IMO, it's programmability / script-ability. And Python (again, imo) is a much better language than bash -- hence a shell based on it would deliver a far better UX than bash ever would.
Clearly the Bourne shell and its descendents must have been doing something right.
The language has nothing to do with why someone picks a shell. They just get used to something, it becomes good enough, and they get on with life. We don't need the most powerful, the most flexible, the most efficient thing. We just need something simple that works. Bash works, so stop nit-picking.
As a former Sun consultant, the most common question I had to fend from customers during those 10 years was the lack of a printf. Fortunately, Odersky has much better taste & Scala shipped with a printf on day 1 in Predef.scala, via Console(https://github.com/scala/scala/blob/v2.10.1/src/library/scal... )