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

Shell Style Guide

google.github.io

Post reply on HN
Print view View original

211–220 of 336 posts

Re: Shell Style Guide

#211

Post by JepZ »

tootie wrote: post #18

I absolutely hate coding in bash or looking at bash or suddenly being in Windows and being up a tree because bash isn't supported well (it is now if you install WSL). I only use bash to set environment variables and maybe string together 2 or 3 build commands. If I need so much as an if statement, I'm going to switch to a real programming language.

Well, I love and hate bash at the same time.

I love the way of writing scripts. You start with a simple command and keep piping and saving the output to other functions and commands until you reach the desired outcome. While doing so, you can simply wrap every command into wrapper functions and have the entire arsenal of cli applications at you disposal. While not having to care about such esoteric/complicated/efficient stuff like data types as everything is a string until you have a command which knows how to interpret it otherwise.

But at the same time those scripts tend to be very slow, lavish about resources (e.g. compared to compiled languages C/Go/Rust) and the practical/secure syntax is just awful. When simply saving the output of a command to a variable uses six special characters, you know you are coding (s)hell:

  a="$(echo fun)"
Another very deep misconception is the test command in form of the square bracket '[' which leads to the very error prone concept of simple if commands which are very picky about whitespaces.

Despite the rough syntax I really enjoy writing bash scripts. Maybe its just that I am able to solve everyday problems with just a very few lines of code.

Re: Shell Style Guide

#212

Post by occams_chainsaw »

curun1r wrote: post #191
no_wizard wrote: post #156

I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the w…

I actually like python, the language. I think it balances the needs of a dynamic language well and I like that it is, at least, strongly typed. My hate is entirely directed at python, the environment and tooling around the language. Other languages have figured this stuff out and python just hasn't. And the horribly managed 2.x -> 3.x migration made things even worse. I get that it is enjoyable to program in and I th…

There's a bit of bias in that you're most likely to really notice something's in Python when it breaks... And the AWS client is terrible itself. And then you have a lot of stuff like Deluge where you'd never notice it's in Python until you checked under the hood.

Re: Shell Style Guide

#214

Post by Sir_Cmpwn »

dang wrote: post #197
Sir_Cmpwn wrote: post #78

Earlier quoted context omitted.

>Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation of javascript and javascript itself? Javascript is no more "standardized" than SQL is standardized. Every RDBMs implements their own flavor of SQL just like browsers…

> This is nonsense [...] You're off your rocker. Come on Drew, you know better than to do this here, regardless of how wrong someone is. If senior users set this kind of example how can we tell new ones not to? https://news.ycombinator.com/newsguidelines.html

You're right, I'm sorry.

Re: Shell Style Guide

#215

Post by occams_chainsaw »

LinuxBender wrote: post #86

I write long bash and perl scripts. I keep things neat and tidy most of the time. My "temporary workarounds" are still in use today, in production, so I must have written them well enough for people to understand. I see a lot of debate around preferences at the risk of becoming a funny title on n-gate. Just use whatever languages you know best. If it follows the best practices of that language, someone can port it to…

My "temporary workarounds" are still in use today, in production, so I must have written them well enough for people to understand.

Maybe the reason the temporary workarounds persist is because nobody understands them well enough to replace them ;)

Re: Shell Style Guide

#216

Post by saagarjha »

Nimitz14 wrote: post #183
jerf wrote: post #122

Earlier quoted context omitted.

I said Python wasn't going to be more concise. I said it has a variety of other useful properties. For instance, at least as I write this, you have "cut -d’-‘"; I assume you meant apostrophes (something getting too polite in a c&p, I assume) but the apostrophes are unnecessary, but you're so used to the compromises in shell I talked about you probably put those in there automatically. I'm not criticizing that; it's a…

You seem to be imagining some sort of situation where bash is used to deal with input from customers (random users). You do not use bash for that. Filenames with spaces (lol) do not happen unless you do it yourself. Bash is useful for productivity when getting stuff done. For the work I do (where code never comes close to a customer and one-off tasks are common), if a candidate were to write a python script for the e…

> Filenames with spaces (lol) do not happen unless you do it yourself.

This is a cop out. File names can totally contain spaces, and the difference between the Bash and Python solution is that one will continue to work when a file with spaces inevitably shows up and one will fail, possibly silently.

Re: Shell Style Guide

#217

Post by BlackLotus89 »

LinuxBender wrote: post #86

I write long bash and perl scripts. I keep things neat and tidy most of the time. My "temporary workarounds" are still in use today, in production, so I must have written them well enough for people to understand. I see a lot of debate around preferences at the risk of becoming a funny title on n-gate. Just use whatever languages you know best. If it follows the best practices of that language, someone can port it to…

Nothing against you or your long perl scripts (wrote perl for a few years as well), but at my current job there are perl scripts as well, for legacy reasons. The scripts where written 20+ years ago to compliment our mail systems and identy management. Today nobody fixes those scripts or replaces them and finding a replacement solution for the underlying systems is nearly impossible, because nobody understands all the perl scripts or dares to touch them. Our dns management can't handle wildcards and sub-sub domains (easily) and every time something like this is needed there is one person who needs to manually add this. Anyway the point I was trying to make is that temporary soluyions often stay because of other reasons than perfection.

On the flip side I solve every problem at first through bash or python scripts as well and aolutions tend to be permanent, so we are in the same boat.

Re: Shell Style Guide

#218

Post by IdiocyInAction »

arca_vorago wrote: post #189
no_wizard wrote: post #156

I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the w…

It's because so many here on hn are the compsci theoritical programmer, sysadmins are dying devops is everything, kind of people who don't actually support production systems other than maybe their particular depts single page webapp, etc... Hn has a problem with people living in the SV filter bubble seeing everything through that lens... in the real world, bash is still a king. When your devs shit out some bad code…

Don't know if I would say that bash has a low barrier of entry. I find doing stuff in Python far more intuitive than in bash, it certainly has its quirks. I agree on the rest though.

Re: Shell Style Guide

#219

Post by jolmg »

davidcuddeback wrote: post #121
nvarsj wrote: post #105

Earlier quoted context omitted.

I really don't like the `/usr/bin/env bash` approach (it came from the ruby world I think?). It's less portable than /bin/bash in my experience - I've been in environments, usually older ones, where it doesn't work at all. But /bin/bash works everywhere. You also can't pass command line arguments. And it's slightly more complex than just invoking /bin/bash.

> It's less portable than /bin/bash in my experience /bin/bash breaks on FreeBSD, which installs Bash at /usr/local/bin/bash. /usr/bin/env bash works though. > You also can't pass command line arguments. Are you sure about that? Given this script: #!/usr/bin/env bash echo "args: $@" it outputs: $ ./foo 1 2 3 args: 1 2 3 Is that what you meant?

He probably means you can't:

    #!/usr/bin/env bash -ex
but you can:

    #!/bin/bash -ex

Re: Shell Style Guide

#220

Post by saagarjha »

andrewmcwatters wrote: post #142
dvfjsdhgfv wrote: post #51

> Indent 2 spaces It's interesting how quickly the 2-space indent became the new norm

I'm very curious about why. In 8-space tab sizes, you have to very, very carefully think about what you're fitting on that 80-col line after having in most cases, already removed 10% of your column space. A lot of C resulted in single character variable names and abbreviations that sacrificed immediate readability, but with domain knowledge that gets resolved with time. On the flip side of things, you have developers…

…I'm not seeing a strong argument for either in your response.
Post reply on HN