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

The Bash Hackers Wiki

wiki.bash-hackers.org

Post reply on HN
Print view View original

11–20 of 89 posts

Re: The Bash Hackers Wiki

#11

Post by heavyset_go »

dijit wrote: post #3

Bash was the first scripting language I ever got "good" with. (I put "good" in quotes because while I could get basically anything done, I promise that it was not good looking). However, I feel like it left me a bit brain damaged, I still think in terms of quotation quirks and "sub-shells" even in proper languages such as python or rust. It also left me a bit weird when thinking about concurrency, because I never con…

> Bash was the first scripting language I ever got "good" with.

Same here. However, it wasn't until I used other languages to manage systems, or glue utilities together, that I really started appreciating Bash.

Bash can be ugly and pretty gross at times, but there are some problems that can be solved quite elegantly with it.

> It also left me a bit weird when thinking about concurrency

Funny, one of the things that I like the most about Bash is how simple it makes concurrency, especially when you pair it with GNU parallel.

Re: The Bash Hackers Wiki

#12

Post by AceJohnny2 »

This website has been my go-to reference when hacking together Bash scripts. I can never remember the exact syntax of parameter substitution, and how do I do arithmetic substitution again? What's all the 'set -o' options?

I've since switched to Zsh, and while its documentation is extensive, it's basically one fat book and is far from being as accessible or navigable at this excellent wiki.

Re: The Bash Hackers Wiki

#13

Post by m463 »

I like bash, but I sort of have a rule...

If I am thinking of using advanced features of bash, or I'm over-using grep/sed/awk within the script.... switch to python (formerly perl)

Mostly it's a win with respect to quoting, path manipulation and proper data structures.

Re: The Bash Hackers Wiki

#14

Post by _jal »

m463 wrote: post #13

I like bash, but I sort of have a rule... If I am thinking of using advanced features of bash, or I'm over-using grep/sed/awk within the script.... switch to python (formerly perl) Mostly it's a win with respect to quoting, path manipulation and proper data structures.

Python's major glaring problem as a systems language is dealing with processes. It is just verbose, ticky and annoying.

I have my other issues with it as a systems language that are more idiosyncratic, but for replacing bash, process management is just way too much hassle.

Re: The Bash Hackers Wiki

#15

Post by 0xdeadb00f »

oh_sigh wrote: post #7

https://xkcd.com/927 Is there room for a lightweight scriptable language that takes the place of, say, bash/zsh/korn/fish shell scripts? Please don't say perl/python or sed/awk.

I use POSIX /bin/sh exclusively. It's reasonably lightweight but because of this you loose a lot of the "bash-ism"s. There's ways to work around it though, and the pure-sh-bible[1] is great.

1: https://github.com/dylanaraps/pure-sh-bible

Re: The Bash Hackers Wiki

#16

Post by chubot »

_jal wrote: post #14
m463 wrote: post #13

I like bash, but I sort of have a rule... If I am thinking of using advanced features of bash, or I'm over-using grep/sed/awk within the script.... switch to python (formerly perl) Mostly it's a win with respect to quoting, path manipulation and proper data structures.

Python's major glaring problem as a systems language is dealing with processes. It is just verbose, ticky and annoying. I have my other issues with it as a systems language that are more idiosyncratic, but for replacing bash, process management is just way too much hassle.

I agree, I basically wrote the same thing in the FAQ for Oil:

http://www.oilshell.org/blog/2018/01/28.html#shouldnt-script...

Re: The Bash Hackers Wiki

#17

Post by chubot »

oh_sigh wrote: post #7

https://xkcd.com/927 Is there room for a lightweight scriptable language that takes the place of, say, bash/zsh/korn/fish shell scripts? Please don't say perl/python or sed/awk.

That's what Oil is, except it also runs bash scripts and lets you upgrade seamlessly.

That is, bin/oil is the same as bin/osh with a bunch of shell options on, including 'shopt -s simple_word_eval' which eliminates a lot of the quoting hassles.

You can try it now, but some things will be cut out after optimizing the prototype interpreter (in the name of time):

You Can Now Try the Oil Language http://www.oilshell.org/blog/2019/10/04.html

I'm looking for help too: http://www.oilshell.org/blog/2019/12/09.html#help-wanted

----

Also, I think there is more room than ever, because both Python 3 and Perl 6/Raku are worse for shell-like tasks than their predecessors! Mainly because of startup time and the string abstaction.

We discussed that a couple weeks ago here, and I think it's on the blog somewhere too:

https://news.ycombinator.com/item?id=22156151

Re: The Bash Hackers Wiki

#18

Post by dfox »

anonsivalley652 wrote: post #10

It seems like there is potential for making bash faster. 1. JIT compilation, caching and invalidating on updated source files 3. Rearchitecting similar a-la busybox all of coreutils, sharutils, grep, awk and sed as internal components to avoid forking as much as possible. Tool symlinks back to itself for compatibility. 4. Rearchitecting to simulate sub-shells with threads and local contexts, rather than globals/singu…

I think that there is really good reason why you don't want to do any of that: bash shell and not general purpose language/VM. And I say that as the author of what essentially is point of sale system implemented in bash with ui based on dialog/whiptail...

Re: The Bash Hackers Wiki

#19

Post by _jal »

yeowMeng wrote: post #9
dijit wrote: post #3

Bash was the first scripting language I ever got "good" with. (I put "good" in quotes because while I could get basically anything done, I promise that it was not good looking). However, I feel like it left me a bit brain damaged, I still think in terms of quotation quirks and "sub-shells" even in proper languages such as python or rust. It also left me a bit weird when thinking about concurrency, because I never con…

Bash was the first scripting language I became “good” in too! The skill seems to be regularly devalued in this community, and there is no surprise why (what is collaboration and maintenance for $500). However, it’s hard to ignore why bash masters are born in the first place if better tools exist - shouldn’t the best tool win in the long run? My take is lone wolf hackers working in corporate /_/nix constrained environ…

I used to know someone who worked for a hugeco with really ancient proprietary unix systems. He wrote huge, complicated things in awk.

I think the experience did things to him, but he was the guy to go to for awk questions.

Re: The Bash Hackers Wiki

#20

Post by saagarjha »

anonsivalley652 wrote: post #10

It seems like there is potential for making bash faster. 1. JIT compilation, caching and invalidating on updated source files 3. Rearchitecting similar a-la busybox all of coreutils, sharutils, grep, awk and sed as internal components to avoid forking as much as possible. Tool symlinks back to itself for compatibility. 4. Rearchitecting to simulate sub-shells with threads and local contexts, rather than globals/singu…

If you really care about speed, you probably shouldn't be using Bash.
Post reply on HN