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

181–190 of 336 posts

Re: Shell Style Guide

#181

Post by jamespo »

pas wrote: post #110
coldtea wrote: post #100

Earlier quoted context omitted.

> Python seems to handle complexity better, but only on the surface. (Basically Python has nice data structures, great string formatting, and .. that's it.) It's a complete scripting language, with tons of features, from a comprehensive standard library with something for most needs, to a packaging system, isolated environments, async io, and more. And lots of expressivity in structuring your program (including optio…

> not sure what the above "and that's it" means. That it's not Haskell? Yes, it's not. That scripting in Python is pretty bad. It makes thing harder and at the same time you still have to think a lot about what can go wrong, because there's no enforced error handling.

Some actual examples would be nice; this just sounds like nirvana fallacy.

Re: Shell Style Guide

#182

Post by monocasa »

WalterBright wrote: post #132
bitlax wrote: post #49

Earlier quoted context omitted.

This document agrees with you. - If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python. - If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.

D can be used as a scripting language: #! /usr/bin/env rdmd import std.stdio; void main() { writeln(2); } Just add the shebang line. https://wiki.dlang.org/Why_program_in_D#Script_Fan

C also thanks to Fabrice Bellard

    #!/usr/bin/tcc -run
    
    #include 

    int main() {
        printf("Hello, tcc\n");
        return 0;
    }

Re: Shell Style Guide

#183

Post by Nimitz14 »

jerf wrote: post #122
bm1362 wrote: post #82

Earlier quoted context omitted.

for i in ‘ls /tmp/foo’; do echo $i | grep bar | cut -d’-‘ -f3,4; done Is just so much easier to remember than Python’s OS library, right? I can intuitively string that together but can’t write python without looking up the docs and reading a paragraph about idiosyncrasies.

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 example line of bash I would be strongly biased towards rejecting them.

Re: Shell Style Guide

#184

Post by xapata »

pas wrote: post #165
chronial wrote: post #155

Earlier quoted context omitted.

> You have to do everything manually You are aware that error handling is done via exceptions python?

You are aware that there's no compiler, and that you have to write the try-except-finally? I'm talking about how weak guarantees Python gives compared to Bash about the correctness of the program. It's easy to get None-s, it's too easy to forget to handle file not found or lack of permission.

Maybe you should start raising exceptions instead of returning None.

I've almost never wanted to have my program do anything but crash upon file not found or permission error.

Re: Shell Style Guide

#185

Post by quotemstr »

benmmurphy wrote: post #36

i'm surprised it doesn't recommend using set -e /other flags. [ http://redsymbol.net/articles/unofficial-bash-strict-mode/ ] maybe it is not covered because it is not considered 'style' but i think those flags are some of the most important things you can set when writing a bash script. i guess if you are writing scripts that start other things, and then check their error codes it can be annoying because you have tur…

Please don't blindly follow style guides. Use what works right for you. I generally strongly dislike the decions codified in Google "style guides"

Re: Shell Style Guide

#186

Post by Retra »

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…

Just because all languages have flaws does not mean one language cannot be superior to another. Don't respond to one fallacy by employing another one.

Re: Shell Style Guide

#187

Post by yodsanklai »

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…

> no single language is objectively superior to another

I would say some languages are objectively superior to other for specific tasks. The problem is that very often the task to solve doesn't exactly fall within the realm of any given programming language and one has to make compromise.

As for bash, I use it when I feel it's the best option, but I also think it's the worst programming language that I have to use. I wish there were better options. Are there any modern promising replacements for bash?

Re: Shell Style Guide

#188

Post by peterwwillis »

floatboth wrote: post #150
peterwwillis wrote: post #119

Earlier quoted context omitted.

/bin/sh is most often either the C shell, Dash, or Ash, not the Bourne shell. Bourne shell extensions will cause the script to fail. edit: bourne again shell

/bin/sh shouldn't be a C shell, it's always a POSIX-compatible shell IIRC

I suppose you're right, though the main point is it may not have Bourne-again extensions

Re: Shell Style Guide

#189

Post by arca_vorago »

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 that causes your sysadmin to get a call at 3am... he's using bash to fix your fucking nodejs or whatever fadofthemoment bullshit you decided to run with. Of course entire applications generally shouldn't be in bash... it's like a kit of duct tape, epoxy, and rivets. Of course you should have made the product better, but when it does break, bash can keep it together until you get to the shop.

I also think there is a certain amount of eliteism. It has such a low barrier to entry, it's like some people hate the idea of people being able to program without being programmers.

I've heard it all so much here it just goes in one ear and out the other.

/end bofh rant

Re: Shell Style Guide

#190

Post by davvolun »

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…

The Python hate here is ridiculous. This is Google's [bash] style guide -- Google has chosen to use Python as their general purpose development language so "setting up environments" and pip, virtualenv, pyenv, pipenv all of that stuff is resolved through their standard processes.

So, if you're not Google, then replace "Python" with "our organization's general purpose language", whether that's Ruby, C#, PHP or what-have-you.

The statement is essentially, don't try to do everything in Bash, it's not well-suited for everything and whoever comes along next that has to deal with your 1000 lines bash script is going to want to kill you.

Post reply on HN