sh shell scripts have an ugly syntax ?

Alain De Vos

Alain De Vos

"If" stuff are very ugly, [[ ...]] and [...]. But are there better alternatives ?

Alternatives, e.g. the following program gets more ugly in python. Because of the IO,
#!/bin/sh
cat mytext.txt | sort | uniq > result.txt

What are your opinions about bash or lua ? Some hate bashism.
sh is old can also be a reason to drop it.
 
On one hand, syntax is the least of the problems when writing software. When you write a large software project, 90% of the work goes into planning, design, project management (who does what, how to you stage things, how do you handle bugs, release mechanism, source control). And of that design is particularly important. In comparison, these differences are really minor:
Code: 
if elefant == flying:
    do_fly(elefant)

if (elefant == flying) {
    do_fly(elefant)
}

if [ elefant -eq flying ] ; then
  do_walk elefant
fi

IF ELEFANT = FLYING THEN
    PERFORM DO_FLY VARYING ANIMAL AS ELEFANT
END-IF

On the other hand, for beginners or really short pieces of code, syntax makes a difference.
 
Modern languages have built-in capabilities for unit tests (1x1 of good programming: write tests 1st, then code until tests pass), constraints, produce documentation from comments etc.pp. To avoid common syntax errors by providing a "better" syntax was one of the design goals of Python. It also allows for the adoption of various programming paradigms, so you can choose the one that fits the problem best to implement elegant solutions (in general, these are easier to maintain). LUA is definitely the way to go for embedded scripting, i.e./e.g. for pkg & zfs. I would not recommend bash(1) scripts just because it provides some handier facilities. Choose standard POSIX shell instead.
 
Ralphbsz, form has also some importance because it frees the mind of doing unnecessary mental juggling.
Remember Einstein inventing a notation which fitted his problem.
What I don't like about python is let's say, trapping signal, difficulty in piping output from one program to another, having to call popen3.
pkg info | awk '{print $1}' | xargs -I {} pkg remove {}
Python is not well fitted to do this I think
And sh scripts are prone to syntax errors I find, just edit /etc/rc.subr ,which you should not do , I know :)
 
As alternative to racket there is kawa,
With objects, and swing.
Both are fast, chicken is slow.

Also ocaml has interesting features.

But doing ,
pkg info | awk '{print $1}' | xargs -I {} pkg remove {}
and for instance doing it interactively and non-interactively and catching errors.
Many languages fail.

PS: As for dynamic scoping, it can be interesting if you invent a new language, because we are short of.
 
It's the function itself (string<?) that is being passed to sort. Here a rough (syntax only) javascript translation:
Code: 
function rackSort(f) {
  return sort(removeDuplicates(File.lines(f)), function(a, b) { return a < b; });
}
 
I personally think shells/fish is very useful to most people; I'd say it's a great replacement for those who like more featureful shells such as bash, ksh, and zsh. For people who don't mind putting up with some annoyances and "fixing up" their shell with the shell's equivalent of $HOME/.profile the same way you'd fix up bash and ksh, there are two shells with strong similarities to each other: shells/rc and shells/es. All three alternative shells are decent when it comes to scripting, but they also all have their own quirks and challenges to overcome. shells/rc is my personal preference. ;)

And there are plenty of other shells with syntax that differs from sh, such as shells/elvish and shells/xonsh, though I admittedly haven't tried any of them.

I think shell innovation is difficult in general. Languages like Python and Perl are powerful, yet verbose, while sh sacrifices such powerful features in favor of a less verbose syntax full of symbols rather than words in English or some other language, which contributes to its poor readability. In addition, it still needs to be usable in an interactive session. A balance between those requirements (and possibly several others) must be struck, so sacrifices must be made somewhere.

On top of all of that, a new shell deviating from existing conventions can be problematic when attracting new users or porting scripts. In the case of fish, you couldn't use something like command1 && command2 until v3.0 ( command1; and command2 was fishy).

Ultimately, sh is the most portable syntax, but there are definitely better shells, whether you're talking about interactive use or scripting.
 
memreflect said:
I personally think shells/fish is very useful to most people; I'd say it's a great replacement for those who like more featureful shells such as bash, ksh, and zsh. For people who don't mind putting up with some annoyances and "fixing up" their shell with the shell's equivalent of $HOME/.profile the same way you'd fix up bash and ksh, there are two shells with strong similarities to each other: shells/rc and shells/es. All three alternative shells are decent when it comes to scripting, but they also all have their own quirks and challenges to overcome. shells/rc is my personal preference despite it not even supporting tilde expansion. ;)

And there are plenty of other shells with syntax that differs from sh, such as shells/elvish and shells/xonsh, though I admittedly haven't tried any of them.

I think shell innovation is difficult in general. Languages like Python and Perl are powerful, yet verbose, while sh sacrifices such powerful features in favor of a less verbose syntax full of symbols rather than words in English or some other language, which contributes to its poor readability. In addition, it still needs to be usable in an interactive session. A balance between those requirements (and possibly several others) must be struck, so sacrifices must be made somewhere.

On top of all of that, a new shell deviating from existing conventions can be problematic when attracting new users or porting scripts. In the case of fish, you couldn't use something like command1 && command2 until v3.0 ( command1; and command2 was fishy).

Ultimately, sh is the most portable syntax, but there are definitely better shells, whether you're talking about interactive use or scripting.
Click to expand...
Jeez, give some love to zsh! Pah-leez! :)
 
I personally don't find shell syntax particularly ugly. I dropped Bash for scripting years ago, so there's no [[...]] vs [...] for me.

But maybe it's what you're used to? I've been writing shell scripts for over a decade and it's often the tool I go to first. Looking at Objective-C I'm blinded by the syntax initially and could say I find it ugly.
Admittedly not the syntax, but looking at the style of much C code I find it ugly and non-intuitive (mainly due to the fact that (a) I've done little C, and (b) variable names seem to use excessive use of acronyms and shorthand to make them near indecipherable for anyone not intimate with the program).
 
forquare said:
I personally don't find shell syntax particularly ugly. I dropped Bash for scripting years ago, so there's no [[...]] vs [...] for me.

But maybe it's what you're used to? I've been writing shell scripts for over a decade and it's often the tool I go to first. Looking at Objective-C I'm blinded by the syntax initially and could say I find it ugly.
Admittedly not the syntax, but looking at the style of much C code I find it ugly and non-intuitive (mainly due to the fact that (a) I've done little C, and (b) variable names seem to use excessive use of acronyms and shorthand to make them near indecipherable for anyone not intimate with the program).
Click to expand...
Yeah. Objective C function names sometimes very long indeed. Objective C needs a good IDE.
 
forquare said:
I personally don't find shell syntax particularly ugly. I dropped Bash for scripting years ago, so there's no [[...]] vs [...] for me.
Click to expand...

Shell syntax is well suited for scripting.
If you need a "more powerful" or "more legible" language, it very probably means that you're doing application development and no longer scripting.
Scripting is intended for task automation, the "real work" being done by the applications the script launches.
This means a scripting language needs to make application execution as simple as possible because it's what it does most of the time.
In a programming language, executing another application doesn't need to be simple because your application seldom does it.
(Remember: the Unix philosophy.)
Unlike a script, an application basically parses data (or waits for user input), uses it to produce other data and outputs or persists it.
A programming language thus needs to make data representation as simple as possible.
Scripting and application development are complementary activities, so are their languages.
 
Alain De Vos said:
#!/bin/sh
cat mytext.txt | sort | uniq > result.txt
Click to expand...
To be honest, I don’t see what the problem is with the above little script. Looks fine to me, and I wouldn’t try to rewrite that in any other language.

Well, one thing that I would change is the abuse of cat(1):
sort mytext.txt | uniq > result.txt

Also, sort(1) already has the -u option, so uniq(1) is superfluous, too:
sort -u mytext.txt > result.txt
 
The following is quite readable,
Code: 
#!/usr/local/bin/zsh
function doit {
    a=(do re mi fa sol)
    a[3]=()
    for b in $a[2,4]
        do
            echo $b
        done
}

doit

It has no ";" , which i find weird.
 
Alain De Vos said:
It has no ";" , which i find weird.
Click to expand...
Well, in the bourne shell and its derivatives (including zsh), “;” separates commands just like a newline. So, if you always use newlines for separation, you never need to have “;”.

So, the following three variations are exactly identical:
Code: 
for i in foo bar baz; do echo $i; done
Code: 
for i in foo bar baz; do
        echo $i
done
Code: 
for i in foo bar baz
do
        echo $i
done
Usually, script authors chose the second variation, probably because it comes closest to the structure of other languages.

By the way, if you want to write zsh scripts as portable as possible, the first line should look like this:
Code: 
#!/usr/bin/env zsh
That’s because the location of the zsh binary can differ. Most Linux systems have it in /usr/bin, sometimes it is somewhere under /opt, and the BSDs usually have it in /usr/local/bin. When using the env(1) trick, it doesn’t matter where the zsh binary is located, it just has to be somewhere in the users $PATH.
 
I wouldn't call it ugly. A bit archaic maybe. I got used to it over the years i guess and it's all in the eye of the beholder. If i'd list the languages i consider to be ugly there would probably be a lot of people disagreeing and understandably so.
 
Alain De Vos said:
"If" stuff are very ugly, [[ ...]] and [...]. But are there better alternatives ?

Alternatives, e.g. the following program gets more ugly in python. Because of the IO,
#!/bin/sh
cat mytext.txt | sort | uniq > result.txt

What are your opinions about bash or lua ? Some hate bashism.
sh is old can also be a reason to drop it.
Click to expand...
Do you have to use 'shell'? I am just now learning Lua; however, it does not have 'batteries' included unlike Python, yet I think this is a good thing. If you are not limited to only using 'shell' then maybe Perl would be an option. I know a lot of folks think it is ugly, and could have legacy management issues, but for something quick and dirty I find it is a better solution then Python.

Lua is getting used a number of networking devices and it seems if the industry is leaving Tcl behind, so Lua is a great option for the coming future if that is your targeted sector of the industry.
 
You must log in or register to reply here.
Back
Top