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

31–40 of 258 posts

Re: Pure Bash Bible

#31

Post by [deleted] »

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()

[deleted]

Re: Pure Bash Bible

#32

Post by kamaal »

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…

Inability to use tools like Perl and Emacs is the biggest reason why I have to often break the bad news to people that their week to month long projects(Typically in Python and Java) can likely be done if a few minutes to a day or two, if they knew how to Emacs or Perl well.

Programmers take great pride in freeing accountants and ware house workers from drudgery. But seldom do we look at our work in the same way.

In the real world, most software work is done very similar to digging coal mines with shovels. Laborious manual hand typing jobs.

Re: Pure Bash Bible

#33

Post by kamaal »

masklinn wrote: post #28
harry8 wrote: post #26

Earlier quoted context omitted.

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

Doesn't scale well when you have to stitch more than two commands with pipes, which is a very common use case for Unix CLI utilities.

Re: Pure Bash Bible

#34

Post by autoexec »

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 started out with bash scripts and .bat files and eventually found perl to be the ideal solution to 99% of what I needed as well. I'm still using it for log file parsing and day to day administrative tasks, but I'm starting to pick up python because that seems to be where everyone has agreed to move to.

Re: Pure Bash Bible

#36

Post by harry8 »

masklinn wrote: post #28
harry8 wrote: post #26

Earlier quoted context omitted.

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

yeah sure subprocess.check_output(). If you ever dealt with much perl you know how much more pleasant and easy launching processes was in that language - like shell. Python is great, I'm not on the "bash python" wagon. Launching processes, getting the output, munging it and shoving it at another process is more fiddly and less natural in python. If you want to use that as evidence that I'm a garbage developer go ahead, I realise I'm not writing a carefully researched paper here with examples.

In Perl you literally took the part of your shell pipeline, quoted it and opened it like any other file.

    ./output_generator | wc -l
    becomes

    open(SRC, "output_generator|");
    open(WC, "|wc -l);
And you do whatever you want with those filehandles. It's been ages since I wrote any perl. I miss it.

Re: Pure Bash Bible

#37

Post by daitangio »

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 am slowing moving from bash to python for my utility script. I was unable to love Perl, I think this weired syntax is a very bad choice.

Anyway bash is still faster to use, and a lot of Unix services are based on it. The book is well written and have a great added value. Thank you for sharing!!

Re: Pure Bash Bible

#38

Post by grewil2 »

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…

Yes, Python is the Cobol of script languages.
Post reply on HN