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

321–330 of 336 posts

Re: Shell Style Guide

#321

Post by thrwwy12345 »

dang wrote: post #200
thankthunk wrote: post #167

Earlier quoted context omitted.

> This is nonsense. I am very familiar with web browsers. Javascript is standardized as ECMAScript: As I said, it is standardized as SQL is "standardized", but every browser implements their own flavor just like every database server. You aren't familiar with anything. That much is obvious. > You're off your rocker. It's funny how my comments are flagged but not yours when you've been spouting nonsense. > Here is a d…

We've banned this account for repeatedly breaking the site guidelines. Would you please not create accounts to do that with? If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. https://news.ycombinator.com/newsguidelines.html

A quick question. How proud are your parents that you moderate comments on a silly forum? Do they brag about your "career" during family gatherings on thanksgiving? Do you ever wake up and realize that you moderate comments for a living and get depressed/suicidal? Can you think of a more worthless existence that moderating comments? I commend you for not jumping in front of a train or jumping off a bridge. It takes real fortitude for someone so useless to keep going.

Re: Shell Style Guide

#322

Post by protomyth »

gerrard00 wrote: post #284
protomyth wrote: post #208

Earlier quoted context omitted.

Passing text means that every single one of the thousands and thousands of unix cli tools that accept stdio will work in your pipeline. It also means every one of those thousands and thousands of Unix clip tools needs to have a parser to turn that text into some sort of structure to operate on.

Which allows them to determine exactly the best way to do that for their purposes. I just run the command and it magically works. It'll be a long time before the Powershell ecosystem has a fraction of tools that are compatible with it's .NET object pipeline.

Which allows them to determine exactly the best way to do that for their purposes. I just run the command and it magically works.

Up until someone changes the text output of the program and it all goes bad. Never mind the maintenance headaches that basically get solved by people moving their command lines into databases where typing happens.

It'll be a long time before the Powershell ecosystem has a fraction of tools that are compatible with it's .NET object pipeline.

That's more a function of age and developers than the typing itself.

Re: Shell Style Guide

#323

Post by lambda »

enriquto wrote: post #312
lambda wrote: post #90

Earlier quoted context omitted.

I'm one of those people who finds perverse pleasure in writing portable Bourne shell, and doing so correctly. I know I spend far more brain cycles on it than I should; once it gets past a certain complexity limit, I should just switch to Python. But I always say "It's just a little bit more code, there must be a good way to do this," and there generally is, but only after passing over several bad ways to do it first.…

> One of the constraints I impose is that spaces in pathnames should always be handled correctly; I tend to do the exact opposite. If a filename has spaces in it, i like my script to fail spectacularly while insulting the user (who is typically me....) Filenames are variable names. It makes no sense to allow spaces in them.

I need to deal with end user data a lot; which frequently has spaces in it.

Re: Shell Style Guide

#324

Post by MattSteelblade »

mauvehaus wrote: post #59
dijit wrote: post #50

Earlier quoted context omitted.

Unless you want secure strings.. then it complains about "Crypt32.dll" not being available.

Or want to pipe data without PowerShell mangling it[0] PowerShell is materially worse than bash for a great many purposes because of this design choice alone. [0] https://brianreiter.org/2010/01/29/powershells-object-pipeli...

The particular example this user complains about is piping binary data to file. It makes use of the Out-File cmdlet which is making (by default) Windows based assumptions as to how to encode this content. They would have been better served by using cURL's native -O parameter. To say that the pipe corrupts it is another thing entirely.

Re: Shell Style Guide

#325

Post by dang »

thrwwy12345 wrote: post #320
dang wrote: post #197

Earlier quoted context omitted.

> 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

> Come on Drew, you know better than to do this here, regardless of how wrong someone is. But I wasn't wrong. I was right. But you wouldn't know that because your a gender studies major and not a CS major. > If senior users set this kind of example how can we tell new ones not to? And yet no flagging and no ban. How hypocritical of you. The guy instigated it and yet you banned the victim rather than the victimizer. A…

"Regardless of how wrong someone is" does not imply that anyone was wrong. It just says that even if they're wrong, other users must remain civil. That's why we use that wording.

Re: Shell Style Guide

#326

Post by michaelcampbell »

peterwwillis wrote: post #119
moviuro wrote: post #96

Earlier quoted context omitted.

It is, but don't forget it's a guide for Google engineers on the Google machines. People who share code for the world to use should use: - `#!/usr/bin/env bash` - or `#!/bin/sh` for POSIX shell scripting

/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 is most often either the C shell,

Never once have I ever seen this. In 25+ years.

Re: Shell Style Guide

#327

Post by endtime »

zippitydoodah68 wrote: post #255
endtime wrote: post #204

Earlier quoted context omitted.

Exhibit A: When I joined Google Fiber, one of my first projects was converting a (POSIX) shell script that had grown to 1200 lines to Python. It became something that anyone could modify, including interns, rather than something that required at least a code review from our L7 tech lead, whose time was better spent elsewhere (he was the author and our only competent shell programmer).

That is mind blowing for me in a couple ways. * You have (at least) seven tiered support structures. * You have only one 'competent' shell programmer in your 'reachable' project scope. No wonder these types of language policies are in place.

I don't know what you mean by seven tiered support structures. My tech lead was a Senior Staff Software Engineer, L7, level seven, etc. Just meant that he was a relatively senior guy (not that he didn't get his hands dirty, there were just better places for him to do so). There are lots of levels on Google's SWE job ladder.

And maintaining a 1200 line shell script that can brick hardware in people's homes and disable their WiFi (or internet access altogether) is something to be careful with. There were five or so SWEs doing wifi-related things for Fiber (including me and one other person new to the team), and yes, he was the only one of us who knew shell well enough to reliably catch mistakes. He was a few years older than the rest of us, maybe that's why.

I have a BS in CS from Georgetown and a MS in CS from Stanford. I don't think I ever had a class at either school that required me to write a single conditional statement or loop in shell. I probably never would have picked it up at Google either if I hadn't joined an embedded team.

Re: Shell Style Guide

#328

Post by endtime »

zippitydoodah68 wrote: post #318
fjsolwmv wrote: post #303

Earlier quoted context omitted.

It's been decades since "writing a 1000 line script" was best done in shell, if there ever was a time. Someone with that much experience ought to be a very senior engineer.

I have shell libraries that generate code via here documents and other templating that are > 500 lines. That is about as far as I reasonably go. Note that these are function (and scope specific variables (with hopefully unique namespaces)) only code bases with copious comments and references to underlying tools.

The script in question was an interface for controlling WiFi (hostapd, wpa_supplicant) in a variety of ways, abstracting across different chipsets.

Re: Shell Style Guide

#329

Post by pas »

saagarjha wrote: post #224
pas wrote: post #103

Earlier quoted context omitted.

Why wouldn't you install Bash then, if you want to run shell scripts on those platforms? I mean, what are the use cases? Where universality is important (so let's say when someone embeds scripts in Makefiles), I understand the need for POSIX, but other that I can't even come up with a good use case for having sh as default. (Maybe to save space, you ship the embedded device or Docker container with sh, sure, but then…

> Why wouldn't you install Bash then, if you want to run shell scripts on those platforms? Busybox is a thing. Many embedded devices don't have the luxury of installing Bash–you're stuck with what you've got.

But what would a script do in such a limited situation? There are a lot of narrow use cases, but those are very much platform dependent, so no reason to use POSIX everywhere. Use whatever is best on that specific busybox thing.

Re: Shell Style Guide

#330

Post by pas »

tormeh wrote: post #247
pas wrote: post #110

Earlier quoted context omitted.

> 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.

Yeah, even Java doesn't force you to handle errors. Please, calm down. "Scripting" in a compiled language is not practical. People use the word "script" for a reason - it's because they don't want to deal with a language that forces them to think about everything that could go wrong. For some tasks that's perfectly sensible. For other tasks, there is Rust, Haskell and many others.

Checked exceptions are nice. You can use them if you want to make them part of your API surface.

> "Scripting" in a compiled language is not practical.

The premise is that scripts grow, and you should switch to Python. Which might be okay for Google, but seems to be only a very small step up from Bash, if any at all. (I've outlined the reasons, why I think it's not worth it.)

I do a lot of scripting, in Bash, and when that stars to grow on me, it's time to think about the problem for real. And usually a blind rewrite in Python is not the way to go.

> For some tasks that's perfectly sensible.

Those are the one-off scripts, no? Anything that should run with some regularity, anything that should be reproducible, that handles valuable data, is not something that should be cobbled together in bash/python and thrown into /etc/cron.d . Or apparently that's how Google rolls.

Yeah, well, maybe not everyone is an SRE, so the use case here seems to be build scripts and other not-so-critical scripts, that still have to be maintained, where knowledge of Bash/POSIX-sh is not really assumed, it should just work for anyone who checks out the repo.

Post reply on HN