Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safe ways to do things in bash

github.com

Post reply on HN
Print view View original

231–240 of 255 posts

Re: Safe ways to do things in bash

#231

Post by adrianmonk »

koolba wrote: post #8

From the article: > Should I use curly braces? Bad: some_command $arg1 $arg2 $arg3 Extra bad (cargo culting unnecessary braces): some_command ${arg1} ${arg2} ${arg3} Correct: some_command "${arg1}" "${arg2}" "${arg3}" Better: some_command "$arg1" "$arg2" "$arg3" > In the "extra bad" and "correct" examples, braces compete with quotes under the limits of tolerable verbosity. > Shellharden will rewrite all these variant…

I don't think your example backs up your point about it being easier on the eyes. This would also work:

    "$foo bar baz"
Since there's a space after foo, the braces don't actually do anything and thus _can_ be eliminated. Your other points make a decent argument for _not_ eliminating them even though you can, but removing extra characters makes it much easier to read.

Re: Safe ways to do things in bash

#233

Post by Silhouette »

wheaties wrote: post #230
h1d wrote: post #153

Earlier quoted context omitted.

I think it's time people start using something better than bash/zsh that is decades old, like fish or even come up with a more modern shell. Even by looking at these examples, you see it has less verbosity like "then" and "do", you can reference arguments as $argv instead of cryptic $@ and exit status code as $status instead of $? which is confusing with $! and the likes. https://blog.codeship.com/lets-talk-about-she…

What's wrong with something that's decades old? Bash is great for command line and small scripts. It's once you surpass 100 lines where things get problematic. At that point, you're not writing a shell script, you're writing a tiny application and need to treat it as such.

What's wrong with something that's decades old?

In the case of shells, not benefitting from the extra decades of experience. There are some horrible things that you can do with Bash just by mistyping a single character or using the wrong type of quotes or failing to appreciate how something will expand in some edge case. This is not a desirable property for an environment that people use after being paged at 4am, while their employer is losing $XXX,000/minute because something critical is down, and where the half-asleep operator is one short command away from deleting the universe without so much as a confirmation prompt.

Re: Safe ways to do things in bash

#234

Post by sxv »

yAnonymous wrote: post #179
emmelaich wrote: post #147

Earlier quoted context omitted.

I probably have a similar history but I've come to the belief that you should not use Bash if you're doing anything fancy or long (>10 lines). Just use Perl, Python or Ruby. One or all of them is installed on every machine you are likely to use.

Is there an easy way to run shell commands in Python, like backticks in PERL, Ruby or even PHP? I'd really like to use Python more often, but most of the time it only complicates things with those verbose syscalls.

os.system() (https://unix.stackexchange.com/a/238185)

Re: Safe ways to do things in bash

#235

Post by h1d »

znpy wrote: post #215
h1d wrote: post #211

Earlier quoted context omitted.

Why can you not modify the editor environment that you use often? Hard to see I need to deal with environments where I can do nothing but keep the default every time I use it. Once you get the speed that is tuned to your liking, the default sounds like you're walking with legs strapped.

> Why can you not modify the editor environment that you use often? Because I am not the only one accessing those environments (please note the plural here). Currently there are about 13 other sysadmins in my team and we manage clients infrastructures among other things (managed services). From time to time someone from another team accesses those environment (not a sysadmin, but still familiar with the bash shell).…

How hard is it to create a user for each of the system admins?

It seems it's not a good practice to share a single account as it makes it hard to tell who did what.

Re: Safe ways to do things in bash

#236

Post by zwischenzug »

brazzledazzle wrote: post #167
h1d wrote: post #155

Earlier quoted context omitted.

It's time we need a better shell than bash instead of thinking it's great after bleeding with it for years and gets used to it.

I’d vote for PowerShell in a heartbeat. It passes real objects instead of strings. It’s cross platform and open source. It’s imperative but borrows some functional concepts.

As I say in the talk (and get a big laugh) 'Powershell is boring. It's too well-designed.'

Re: Safe ways to do things in bash

#237

Post by zwischenzug »

h1d wrote: post #155
zwischenzug wrote: post #127

Earlier quoted context omitted.

I did a talk on this a while ago: https://www.youtube.com/watch?v=pb3k0sGKrjQ&t=457s 'Take bash seriously'

It's time we need a better shell than bash instead of thinking it's great after bleeding with it for years and gets used to it.

The title 'bash is awesome' was explicitly _not_ what I wanted it to be called. If you watch the talk you'll see what I meant.

Re: Safe ways to do things in bash

#238

Post by zippitydoodah68 »

freedomben wrote: post #121
antris wrote: post #113

Earlier quoted context omitted.

What is your opinion on using other languages to augment bash? Awk, perl etc.

I personally consider awk, sed, grep, cut, etc. to be "part" of bash. I don't think I ever write a script without invoking those venerable tools at least once. I often have many pipes, such as some_command \ | grep -E 'some.*regex$' \ | sed -e 's/erase_text//g' \ | sed -e 's/erase_more//g' \ | awk '{ print $2 }' \ | cut -d ':' -f 1 I used to reach for Perl one-liners a lot, and still do sometimes when I need a gross…

These types of pipelines are why bash and the traditional tools are so maligned. Expert knowledge of sed|(g)awk|bash tools is necessary otherwise you end up with companies telling you that you can't use them.

some_command | gawk ' /some.*regex$/ {gsub(erase_text,"");gsub(erase_more,"");split($2,a,":"); print (length(a[1]) ? a[1] : "STRING ERROR")}'

Re: Safe ways to do things in bash

#239

Post by Annatar »

Liquid_Fire wrote: post #176
Annatar wrote: post #137

" Should I use backticks? Command substitutions also come in this form: Correct: "`cmd`" Bad: `cmd` While it is possible to use this style correctly, it looks even more awkward in quotes and is less readable when nested. The consensus around this one is pretty clear: Avoid." This is how one can tell a rookie just learning to program in shell: usage of $() syntax is limited to Bourne family of shells which implement t…

I think you might be confusing $() with (). There is no functional difference between backticks and $(), the only difference is in how they are parsed with regards to escaping. There is no subshell involved in either case.

After I‘ve been professionally programming in the original Bourne shell, tcsh, ksh for more than 30 years, you took it upon yourself to tell me that I‘m confusing $() and ()? Only on “Hacker News”. Appalling.

Re: Safe ways to do things in bash

#240

Post by Annatar »

posix_me_less wrote: post #174
Annatar wrote: post #137

" Should I use backticks? Command substitutions also come in this form: Correct: "`cmd`" Bad: `cmd` While it is possible to use this style correctly, it looks even more awkward in quotes and is less readable when nested. The consensus around this one is pretty clear: Avoid." This is how one can tell a rookie just learning to program in shell: usage of $() syntax is limited to Bourne family of shells which implement t…

> "This is how one can tell a rookie just learning to program in shell: usage of $() syntax is limited to Bourne family of shells which implement that particular POSIX specification aspect. Backticks, on the other hand, although they incur a performance penalty since they spawn a subshell, make one's code instantly portable across all UNIX-like operating systems and even across disparate shell families, as they work…

“Long live the GNU/Linux hegemony and monoculture, the only truth and true religion”.

Lovely.

Post reply on HN