Live data from Hacker News

The Bash Hackers Wiki

wiki.bash-hackers.org

51–60 of 89 posts

Re: The Bash Hackers Wiki

#51
post #14
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.

99.9% of all process management can be done with oneliner subprocess.check_output. Not verbose at all and much safer.

Biggest mistake people do is bringing bash idioms into python, like trying to pipe the output through head/cut/tail/grep/sed instead of just using string operators like endswith/in/startswith/re. If you do that then process managment will be more verbose, but it is in bash also unless you ignore decent error handling like $PIPEFAIL[0] which many many scripts actually do unknowingly. For those other 0.1% of the places where you actually need a pipe then just accept that you have to write 4 lines instead of 2, you will save thousands of lines in other places. For parallel running processes &, jobs, nohup and wait in bash isn't exactly convenient either if you are interested in the results, so there it's a tie vs POpen if i'm being generous.

Re: The Bash Hackers Wiki

#52

Clicking around, I am glad to see portability to non-bash shells covered in some topics, despite the name of the site. It seems to me like sometime in the last 10-15 years, what we used to call "shell scripting" became "bash" in popular discourse. I myself learned to write shell scripts in times and places where bash was the most popular default, but I never thought of it as writing intentional bashisms, but a set of…

I think bash has become the new name for "shell", in the same way kleenex and hoover became names for product categories, rather than brands.

Re: The Bash Hackers Wiki

#55
This, Greg's wiki and #bash@freenode is how I became a bash nazi to my peers.

Just hanging out in #bash@freenode you learn so much best practice. Like sub-shell quotation, variable capitalization, parameter expansion, read usage and much more.

Re: The Bash Hackers Wiki

#56
post #49
post #48

Earlier quoted context omitted.

I'm sorry, but for the type of work he is suggesting (bash script equivalent), you don't need anything besides the standard library. I cannot think of a single system I have used in recent decades that didn't come with python installed by default. For all intents and purposes, Python is as ubiquitous as bash at this point.

My phone and router have bash. Even if pyhton is installed it isn't certain if it is v.2 or 3.

Sounds like Stockholm syndrome to me!

Re: The Bash Hackers Wiki

#57
post #49
post #48

Earlier quoted context omitted.

I'm sorry, but for the type of work he is suggesting (bash script equivalent), you don't need anything besides the standard library. I cannot think of a single system I have used in recent decades that didn't come with python installed by default. For all intents and purposes, Python is as ubiquitous as bash at this point.

My phone and router have bash. Even if pyhton is installed it isn't certain if it is v.2 or 3.

My router has busybox (ash), but not bash.

Neither bash nor python seem to be preinstalled on BSDs.

Re: The Bash Hackers Wiki

#58

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…

Shell has DSL like nature to it so sh actually is better any other language. But it is not easy to perform introspection or ffi. So basically issues develop when you call alot programs with pipe and environmental variables and you need to also have unshare or poll.

Like one program I had. Basically calling bunch programs in a pipeline but need to poll output of some shell async. C or python makes the pipe code complicated while emulating async Io with tmp is also complicated. In a few cases, is to have second program in python or c or perl and send messages over a pipe.

3. and 4. are helpful. JIT not so much since bottleneck seems to to be parsing rather than executing.

Re: The Bash Hackers Wiki

#59
post #9
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 love Python, I am a Python trainer and wrote an into book on it.

But few years ago, I finally learnt how to use shell and it blew my mind.

With a single command, I can split a really large files in 100 based on a particular column or I can aggregate and do whatever I want with a few piped commands, preview any file with sed '3p' file

Sure. I do not write 100lines of awk code, but I believe I have started utilizing some potential of bash and I don't anymore fire up Python shell and write ten lines which then someone has to maintain!

In my org, our Program manager discovered Python and he looks to replace entire unix scripts whoch do exactly what they are required to do, never fail and will work without any changes to Python.

I don't understand that.

I don't want Python to "win" because there are things you can do in bash, if you learn it correctly

Re: The Bash Hackers Wiki

#60
post #48
post #47

Earlier quoted context omitted.

Python needs to be installed, maintained, and every single library will have its list of dependencies (along with breaking API changes once in a while). There's a reason Bash exists: it's everywhere by default and you know it will still work as it works now in x years.

I'm sorry, but for the type of work he is suggesting (bash script equivalent), you don't need anything besides the standard library. I cannot think of a single system I have used in recent decades that didn't come with python installed by default. For all intents and purposes, Python is as ubiquitous as bash at this point.

We use AIX at work and it didn't have Python installed.

We had to install it for a code review tool I built.

But despite Bash's weird syntax, I love how we can do very complex tasks within a few lines.

Post reply on HN