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

241–250 of 336 posts

Re: Shell Style Guide

#241

Post by icedchai »

sanderjd wrote: post #163
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.

I really don't understand the "switch to Python" thing. Bash scripts are good for calling sequences of command line programs. That is not particularly convenient in Python.

It's perfectly convenient. The subprocess module works well enough for such things. Or even the old os.system.

Re: Shell Style Guide

#242

Post by rkeene2 »

oblio wrote: post #175
rkeene2 wrote: post #143

Earlier quoted context omitted.

Tcl meets all of these requirements. I have a Linux distribution whose PID 1 is a Tcl shell and I can setup everything from there without spawning any new processes.

Yeah, but Tcl is old and quite crufty. The docs are a mess, everything is a string, a lot of concepts it uses are not very familiar and/or mainstream (upvar?). A modern take on Tcl is what we need, in my opinion. Surely we should be able to build something nicer 30 years after the first release of Tcl.

I agree that Tcl isn't mainstream and thus a lot of concepts used by Tcl are not mainstream, but other than that it's got a lot going for it.

Tcl's string representation for objects is just a serialization/deserialization mechanism, which seems to be pretty popular in other languages as well.

Additionally all of the cool things in Tcl such as coroutines, threads (as an additional, but included, package), great documentation delivered as man pages, virtual filesystem access, virtual time, safe interpreters for running untrusted code, a stable ABI (stubs) so that compiled extensions can be used for decades, a small memory as well as disk footprint, extremely cross-platform, easy to embed into larger programs as an extension language, easy to compile a large static program with Tcl as the "main" entrypoint, native BigNum support, many thousands of great packages, ....

What would a modern take on Tcl improve on Tcl that Tcl couldn't just build easier ?

Re: Shell Style Guide

#243

Post by textmode »

Original HN title had the word "Google" in it.

According to this document, Google requires Bash.

I do not use Bash. I use Almquist shell. I try to avoid using uncommon "features" or utilities.

I am not a frequent Linux user but whenever I have to use it, all of the hundreds of scripts I wrote using another OS and Almquist shell still work. They all work in Bash.

Over the years, I used this site as a reference:

https://www.in-ulm.de/~mascheck/

Re: Shell Style Guide

#244

Post by Sir_Cmpwn »

hyperpape wrote: post #235
Sir_Cmpwn wrote: post #21

Earlier quoted context omitted.

Google also makes it difficult to compile Chromium on platforms where /usr/bin/python is python 3, because their shebangs are: #!/usr/bin/env python Rather than the more portable: #!/usr/bin/env python3 Notably this causes problems for people on Arch Linux, and in the near future, Fedora. This post is presented as a style guide that others should adopt. Google may have bash ubiquiotously available internally, but the…

I believe your claim that /bin/sh is standardized is incorrect, though I don't know how many actual systems fail to have it present. Source: https://news.ycombinator.com/item?id=17069408 (I checked the 2018 version of the spec, and it says the same).

Aye, I was incorrect. I have pushed a correction, but it will take a moment to appear on the site.

Re: Shell Style Guide

#245

Post by rkeene2 »

blacksqr wrote: post #202
rkeene2 wrote: post #143

Earlier quoted context omitted.

Tcl meets all of these requirements. I have a Linux distribution whose PID 1 is a Tcl shell and I can setup everything from there without spawning any new processes.

>I have a Linux distribution whose PID 1 is a Tcl shell Interested! Available?

Not really, it's really used to setup the environment for a network boot, it supports VLANs and network configuration and loading modules and stuff (even from Tcl virtual filesystems), it's basically just Tcl+TUAPI[1]

[1] https://chiselapp.com/user/rkeene/repository/tuapi/doc/trunk...

Re: Shell Style Guide

#246

Post by ZephyrP »

monocasa wrote: post #182
WalterBright wrote: post #132

Earlier quoted context omitted.

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; }

tcc is neat software and I used it for some time almost exclusively for "-run", but after many years I ultimately replaced it with a small shell rc-function for compiling, linking and running a C/C++/x86/etc. file from the shell.

I think it's nicer.

    #!/bin/sh
    crun() {
        local file="$1"
        shift
        local exepath="$(mktemp)"

        if [[ "$file" =~ \.c$ ]]; then
            gcc -g -Wall "$file" -o "$exepath" || return $?
        else
            echo "no filetype detected"
            return 126
        fi

        "$exepath" "$@" & fg
    }
... along with a more sophisticated version for .zshrc as well.

    #!/usr/bin/env zsh
    function crun {
        zparseopts -E -D -- -gcc::=use_gcc \
                  c:=custom_compiler \
                  o+:=copts \
                  Wl+:=lopts \
                  -dump::=dump_asm \
                  v::=verbose \
                  h::=usage \
                  g::=debug

        if [[ -n $usage ]]; then
            cat 

              --clang     (default) use clang for C & C++ files
              --gcc       use GCC for C & C++ files
              --dump      dump assembly of program
              -o          supply an option (e.g -o -Wall)
              -v          verbose
              -g          debug

            Compiles and runs a C, C++ or x86 Assembly file.
            EOF
            return 126
        fi

        # select unique entries of `copts` and then slice copts[2..] (copts[1]
        # contains the flag, e.g "-o")
        local file=${@[-1]}
        local options=${${(u)copts}[2,-1]}
        local exepath="$(mktemp)"

        if [[ $file =~ \.(cc|cpp|cxx)$ ]]; then
            local compiler="clang++"
            $compiler -std=c++1z -g -Wall -Weffc++ ${=options} $file -o $exepath
        elif [[ $file =~ \.c$ ]]; then
            local compiler="clang"
            [[ -n $use_gcc ]] && ccompiler="gcc"
            $compiler -g -Wall ${=options} $file -o $exepath
        elif [[ $file =~ \.(s|asm)$ ]]; then
            local objpath="$(mktemp)"
            nasm -felf64 $file -o $objpath && ld $objpath -o $exepath
        else
            echo "no filetype detected"
            return 126
        fi  || return $?

        if [[ -n $dump_asm ]]; then
            objdump -S -M intel -d $exepath
        else
            [[ -n $verbose ]] && echo "exepath: $exepath"
            if [[ -n $debug ]]; then
                gdb --args "$exepath" "$@"
            else
                "$exepath" "$@" & fg
            fi
        fi
    }

Re: Shell Style Guide

#247

Post by tormeh »

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.

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.

Re: Shell Style Guide

#248

Post by tomc1985 »

jolmg wrote: post #236
tomc1985 wrote: post #230

Earlier quoted context omitted.

/usr/bin/env anything is a pain to use with cronjobs

I don't have much experience with cronjobs, but is $PATH not set-up properly in their environment?

I don't remember exactly but it may be $PATH.

I run into this trying to run rvm-managed Ruby scripts in cronjobs. The solution (IIRC) is to explicitly reference the interpreter you want to run in the cronjob line.

Re: Shell Style Guide

#249

Post by nailer »

tbyehl wrote: post #226
nailer wrote: post #148

Earlier quoted context omitted.

Sad to see this downvoted. As a 20 year bash veteran: powershell is the first OS default shell that outputs structured data, and looking at objects and selecting the properties you want is a massive improvement than combining bash with sed/grep/awk to scrape text. Someone bizarrely responds that cmd still exists on Windows for compatibility purposes (though even Win+X starts powershell now) doesn't change this at all…

I'm always amused by these PowerShell threads on HN. How is it that objects are an accepted thing for basically every programming environment in modern use, yet somehow controversial when it comes to the shell? The prayer-based text parsing toolchain sucks. It has always sucked, regardless of platform. We put up with it because it was all that we had. Jeffrey Snover came up with something better and thanks to PS Core…

Yeah - most people would agree that GraphQL is a better way to access data than, say headless Chrome via Puppeteer. Many folk here prefer TeX over Word because the former encourages seperating content from presentation. But when it comes to the shell, suddenly everyone hates the idea.

Re: Shell Style Guide

#250

Post by tomc1985 »

cma wrote: post #239
tomc1985 wrote: post #228

Earlier quoted context omitted.

Shell code can run in a whole bunch of environments that even getting python into can be tricky. initramfs before your drives are mounted, for example... A lot of the discussion on here is mind-blowing, so many pushing to throw out perfectly good tech because it doesn't fit their (limited) worldview.

Micropython can fit :P

Yeah but its another thing to bundle

/bin/sh will always be there

Post reply on HN