Re:Delegating complex treatments to filters in shell program...
by 10165 on Friday May 12, 2017 @01:49PM
(#14326126)
The author's first sentence regarding "novice" shell programmers I think may be applicable to the other submission about shell scripts currently on the front page.
For example, in C the idioms often combine several instructions into a single line, i.e., "nesting". Kernighan suggested nesting in an early C tutorial:
while ( putchar( getchar( ) ) != '\0' )
In the shell maybe it is better to test each "expression" on a line by itself. Or maybe not. I do this anyway.
More often I see on the web that other shell scripters prefer to nest as many commands as they can, perhaps to reduce the number of lines.
For example,
variable=$(command1 $(command2));
This could be alternatively expressed as something like
variable1=$(command2);
# can now test variable1 before proceeding to next line
variable2=$(command1 $variable1);
The result of nesting is subshells and complexity that I am not sure reluctant, occasional shell scripters are prepared to think about.
And if I am not mistaken that was at least part of the problem that Jane Street had in the other submission.
For example, in C the idioms often combine several instructions into a single line, i.e., "nesting". Kernighan suggested nesting in an early C tutorial:
In the shell maybe it is better to test each "expression" on a line by itself. Or maybe not. I do this anyway.More often I see on the web that other shell scripters prefer to nest as many commands as they can, perhaps to reduce the number of lines.
For example,
This could be alternatively expressed as something like The result of nesting is subshells and complexity that I am not sure reluctant, occasional shell scripters are prepared to think about.And if I am not mistaken that was at least part of the problem that Jane Street had in the other submission.