Earlier quoted context omitted.
> This is not the bread and butter of programming... This is, however, the bread and butter of shell programming. > ... "tr --delete --complement"... And, likewise, I'm not sure of the meaning of --delete and --complement, but I do understand "tr -dc". I'd have to look up --delete and --complement to work out what they're the equivalent of.
"This is, however, the bread and butter of shell programming." This is really old-fashioned thinking. The people who have been in this industry for 10+ years all grew up without computers - and thus had to memorize all of the flags, obscure shell commands, and weird regular expression. What was taught in school back then was to do things perfectly the first time, because CPU cycles were expensive, and bugs were time…
Use long flags when scripting
101–110 of 133 posts
Re: Use long flags when scripting
#102Earlier quoted context omitted.
A much simpler solution is to comment your code: # Invoke curl in silent mode (-s), pipe the output to grep # and use an extended regex (-E) to only show the resulting # digits (-o: only print matching text, not the whole line): curl -s checkip.dyndns.org | grep -Eo '[0-9\.]+'
I don't like commenting the how and what; that's what the code is for. Comments are for "why".
Re: Use long flags when scripting
#103Re: Use long flags when scripting
#104Re: Use long flags when scripting
#105Earlier quoted context omitted.
I'm all for being nice, but I think you are missing the point. It's not about flexing knowledge for ego's sake, that's entirely beside the point. No, the source of Unix nerd's retort is the realization that a small set of simple, standardized and very sharp tools performs better over time than an ever-increasing set of intuitive tools to suit a narrow use case. This is not to disparage anyone for writing something li…
> a small set of simple, standardized and very sharp tools This may have been true(r) twenty or thirty years ago, but in a contemporary Unix installation, it is not true at all. The set of tools is often NOT small (there are thousands of them); they are NOT simple (two examples: 1. the ls man page and the huge number of options it takes; 2. shell quoting rules); they are NOT standardized (I regularly run into incompa…
Reading man-pages does do a lot for you. And in my experience, I don't spend a lot of time while on the same engagement/project/whatever writing shell code across BSD/solaris/GNU-linux/etc.
And honestly, if you can write a sophisticated sed substitution for BSD without reading the man page, is there really THAT big of a barrier lying between you and writing the same thing in GNU/Linux, or non-POSIX-compliant sed, or whatever else? You read the man page for 10 seconds and find the flag that means what you want to use. If it's different, you explore.
This is totally not a rant at you, and I sincerely hope you don't take it that way - I just haven't found myself utterly foiled by the differences between say, RHEL v SUSE v BSD recently. There are differences, but hell - there are differences between versions of languages, between terminal emulators (scripts that work in bash but not in zsh and vice versa), etc.
Re: Use long flags when scripting
#106This is very bad advice. I won't thank you for making me check GNU grep's --ignore-case is precisely the same as the very well-known, POSIX'd, -i. And ditto for all the other verbiage that clutter and obfuscate the script's intent. Short options should be used where they're the more typically known and standardised. Long options are for the unusual. grep -iv sed -n tr -dc awk -f ls -tr comm -23 tail -n
I'm a 4th year student in a well-respected CS program, I have used linux off and on for over three years now, and I would consider myself perfectly capable of maintaining a shell script using any of the utilities you mention. However, without checking the man pages I could not tell you the behavior of the -n flag for sed, the -dc flags for tr, the -f flag for awk, or the -tr flags for ls, and I only have a guess as t…
Re: Use long flags when scripting
#107Earlier quoted context omitted.
The difference is that with long flags, even someone without 10 years of POSIX experience knows what's going on. The long example on the OP's article makes a lot of sense to me, even though I'm primarily a Windows user. At the same time, for instance, I've no idea what the -tr flag to ls does, even though I use ls often enough.
You are not a Unix user. You don't know Unix's commands and their common options. If the article is aimed at you and people like you that read your scripts then it's fine but it's akin to commenting "dir /w" in a DOS batch file to explain its purpose. Unix users should not following the article's advice, they should be embracing Unix's style and ethos; it's part of what's made it such a success. BTW, a month of using…
Re: Use long flags when scripting
#108Re: Use long flags when scripting
#109Earlier quoted context omitted.
You are not a Unix user. You don't know Unix's commands and their common options. If the article is aimed at you and people like you that read your scripts then it's fine but it's akin to commenting "dir /w" in a DOS batch file to explain its purpose. Unix users should not following the article's advice, they should be embracing Unix's style and ethos; it's part of what's made it such a success. BTW, a month of using…
Is Randall Munroe a Unix user after 15 years of using it? http://xkcd.com/1168/
Re: Use long flags when scripting
#110This is very bad advice. I won't thank you for making me check GNU grep's --ignore-case is precisely the same as the very well-known, POSIX'd, -i. And ditto for all the other verbiage that clutter and obfuscate the script's intent. Short options should be used where they're the more typically known and standardised. Long options are for the unusual. grep -iv sed -n tr -dc awk -f ls -tr comm -23 tail -n