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

Pure Bash Bible

github.com

Post reply on HN
Print view View original

21–30 of 258 posts

Re: Pure Bash Bible

#21

Post by jigglesniggle »

danielecook wrote: post #16
jigglesniggle wrote: post #4

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

I don’t think it’s pomp. Once I learned Unix pipes and the tools for manipulating data (sed awk cut etc), it just became much faster and easier than writing python scripts that do the same thing. You can literally connect the output of one process to the input of another with a single character. It’s much more complex in python. It also tends to be very portable.

I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree.

This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some warts related to redirection.

The best pattern I have seen is encapsulating business logic into Python or Go and then if really necessary piping it to another script. But, often, if you do this you can just keep the piping internal using data structures.

Unix-pattern facilities work very well for interactive use, which tends to be simple, exploratory, and trial-and-error. But a project's build script may not be simple.

Re: Pure Bash Bible

#22

Post by dvfjsdhgfv »

masklinn wrote: post #10
jigglesniggle wrote: post #4

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

> I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh I would heartily agree. If your shell script grows beyond half a dozen commands or so, you're probably better off rewriting it in just about anything. Python, ruby, go (gorun), rust (cargo-script), or whatever else, doesn't really matter as long as it's not shell.

Or D via rdmd:

https://dlang.org/rdmd.html

Re: Pure Bash Bible

#23

Post by dyanaraps »

jigglesniggle wrote: post #4

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

The shell is my favorite language and I really don't know why.

It's definitely possible to write shell code which properly passes shellcheck's linter though it's an uphill battle to learn the ins and outs and _why_ X is wrong when Y is right.

I even managed to write a full TUI file manager in bash!

https://github.com/dylanaraps/fff

I full understand that there are times when the shell should not be used and when other languages are a better way to solve a specific problem, however I love pushing the shell beyond its supposed limits! :)

Re: Pure Bash Bible

#26

Post by harry8 »

jigglesniggle wrote: post #4

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

Yeah perl was nice when we were allowed to use that. Why doesn't python have something like named pipes?

    f = open("ls|", "r)
    f.read()
    f.close()

Re: Pure Bash Bible

#27

Post by danielecook »

jigglesniggle wrote: post #21
danielecook wrote: post #16

Earlier quoted context omitted.

I don’t think it’s pomp. Once I learned Unix pipes and the tools for manipulating data (sed awk cut etc), it just became much faster and easier than writing python scripts that do the same thing. You can literally connect the output of one process to the input of another with a single character. It’s much more complex in python. It also tends to be very portable.

I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree. This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some w…

My mistake - I managed to completely misinterpret what you meant. I agree with your comment!

Re: Pure Bash Bible

#28

Post by masklinn »

harry8 wrote: post #26
jigglesniggle wrote: post #4

While this is interesting I see doing anything but launching programs with simple text-substituted arguments as too much for bash or sh. Run shellcheck on some of your own code, or the code of even a simple project to see how hard it is to really use bash. Why I think people gravitate towards it is because languages such as python add too much pomp to launching a shell process. A language like perl is usually easier…

Yeah perl was nice when we were allowed to use that. Why doesn't python have something like named pipes? f = open("ls|", "r) f.read() f.close()

I'm not sure what that's supposed to do, but subprocess provides these facilities, although definitely in a more verbose way.

    f = Popen('ls', stdout=PIPE).stdout
    f.read()
    f.close()
alternatively given this exact behaviour:

    run('ls', stdout=PIPE).stdout

Re: Pure Bash Bible

#29

Post by hagreet »

NegativeLatency wrote: post #6

Kinda cool, I don’t write or read much bash and tend to stick to sh compatible stuff. There are some neat tricks in here but they don’t seem very readable compared to perl/awk/sed.

Yeah, I also don't look at things like

``` trim_string() { # Usage: trim_string " example string " : "${1#"${1%%[![:space:]]}"}" : "${_%"${_##[![:space:]]}"}" printf '%s\n' "$_" } ```

and think: "I should use bash more".

Bash is nice for making simple things simple but for complicated things it's just shitty. I used to think that this is due to the complicated quoting rules which make the simple things simple but tcl does a much better job at that.

In either case I prefer the clean rules of a Python or Perl for anything larger.

Post reply on HN