331–336 of 336 posts
When breaking a pipe into two lines, I find it cleaner to end the first line with pipe instead of backslash. Then I indent the second line. Bash knows a command cannot end with pipe, therefore it's syntactically ok. E.g. cmd1 | cmd2 Instead of: cmd1 \ | cmd2
Earlier quoted context omitted.
Sounds very much like IBM AS400
I’m not sure when you worked on AS/400, but from what I remember there was no xml involved at all , although you had to deal with DB2 and the almost comical table and column names...
Earlier quoted context omitted.
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…
Any code anywhere is worth being careful with and a shell script can be more dangerous than your average glue language (tcl,python,perl) script. I don't see why you need 1200 lines of shell script unless most of it is error handling and safe execution wrapping.
Funny, I've worked at Georgetown and my grandfather went to Stanford. I've written (over 20+ years) good and bad shell scripts. They get better the older I get and they also seem to be (mostly) less than 50 lines. I don't understand why people say these things about edu unless it's intended to awe the easily impressed. Smart is smart and well rounded is well rounded anywhere.
I'm really surprised they went with: #!/bin/bash as opposed to: #!/usr/bin/env bash the latter feels more flexible and dependable for a script to be passed around.
Why is it better than the other statement?
Thanks!
Earlier quoted context omitted.
The modern take on Tcl arrived almost 20 years ago, when "everything is a string" turned into "everything is a typed object with a string representation". The docs are clear and complete, and the concepts it uses make it a powerful and elegant tool.
The docs are clear and complete?!? Has something changed suddenly in the last 5 years? Yes, the docs had a decent API reference but everything slightly higher up than "what parameters this command has" was on that wiki with comments from 2004 marked as out of date by out of date comments from 2007...
Earlier quoted context omitted.
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…
You have deep technical ladders and they may make sense in a place like Google. Who knows. I've seen a couple young men I've mentored go to work at Google and don't hear anything negative from them. Any code anywhere is worth being careful with and a shell script can be more dangerous than your average glue language (tcl,python,perl) script. I don't see why you need 1200 lines of shell script unless most of it is err…