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

41–50 of 89 posts

Re: The Bash Hackers Wiki

#41

Post by CJefferson »

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…

Sub shells are something I don't think get used enough. I would love it if it was easier to spawn extra processes, particularly if those processes could be strongly sandboxed.

Who cares about overflows in your video encoder, if all it can do is make you output broken / different video?

Re: The Bash Hackers Wiki

#42

Post by Galanwe »

heavyset_go wrote: post #11
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…

> 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.

Or xargs :-)

Re: The Bash Hackers Wiki

#43

Post by ShorsHammer »

heavyset_go wrote: post #33
ShorsHammer wrote: post #32

Earlier quoted context omitted.

it's python, requests is one of it's many libraries for the purpose, would actually be quite concerned hiring someone who doesn't know the multiple stdlib solutions for this and still claims ability in python. import json import urllib.request tough hey

I'd be as concerned with someone not opting to use what the documentation recommends[1] in lieu of the stdlib, as I would someone who puts together an awkward Bash script to parse JSON instead of just installing the 50kb package for jq. > The Requests package is recommended for a higher-level HTTP client interface. [1] https://docs.python.org/3/library/urllib.request.html

It's a lot easier to hire people than fire them friend.

The documentation recommends nothing of the sort, it's a direction for consumers. We all live in varied and different worlds, how many varied server environments have you been responsible for all at once? Is it really beyond your amazing programming skills to use the tools at hand in every circumstance? Perhaps it's a chance to demonstrate yet another 3rd party tool which fixes non-existent problems.

It's a few bytes difference in your script that is using requests over the numerous and plentiful stdlib options there.

Re: The Bash Hackers Wiki

#44

Post by tannhaeuser »

asveikau wrote: post #35

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…

An even more important point since the two mainstream desktop Unixen (Mac OS and Ubuntu) ship with zsh and dash, resp., by default.

Re: The Bash Hackers Wiki

#45

Post by lizmat »

badsectoracula wrote: post #26
ofrzeta wrote: post #6

Earlier quoted context omitted.

I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting. You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that. https://docs.python.org/3.7/library/pathlib.html

The nice thing about Bash which can obviously not be said about Python is that Bash scripts will keep working (assuming whatever they call is also there of course) since Bash goes out of its way to preserve backwards compatibility. Considering its legacy, Bash can run scripts more than a decade before Python even existed. The only other scripting language i know of that has similar backwards compatibility is Tcl. Per…

> Perl 6 that was renamed to something else

Indeed, it has been renamed to Raku (https://raku.org using the #rakulang tag on social media).

Re: The Bash Hackers Wiki

#46

Post by lizmat »

chubot wrote: post #17
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/…

> Python 3 and Perl 6/Raku are worse for shell-like tasks than their predecessors! Mainly because of startup time and the string abstaction

Startup time can always be better, agree. But full support for Unicode is needed in this day and age, and that brings overhead, whichever way you do that, and especially so if you want to do it 100% correctly. If you're still living in an ASCII world, then by all means, go for it.

Additionally, in this world of source version control, and virtually unlimited diskspace for source-code, I think using scripts, rather than one-liners, will help better in maintainability rather than using one-liners.

Re: The Bash Hackers Wiki

#47

Post by ekianjo »

ofrzeta wrote: post #6
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…

I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting. You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that. https://docs.python.org/3.7/library/pathlib.html

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.

Re: The Bash Hackers Wiki

#48

Post by epr »

ekianjo wrote: post #47
ofrzeta wrote: post #6

Earlier quoted context omitted.

I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting. You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that. https://docs.python.org/3.7/library/pathlib.html

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.

Re: The Bash Hackers Wiki

#49

Post by tjoff »

epr wrote: post #48
ekianjo wrote: 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.

My phone and router have bash.

Even if pyhton is installed it isn't certain if it is v.2 or 3.

Re: The Bash Hackers Wiki

#50

Post by wodenokoto »

I clicked the config article and it reminded me of 2 major pet peeves:

1) No good way to store config values, nor ones that can be shared with other languages. I might have a set of python applications running in the cloud and a shell script to deploy them, and guess what, I'd like them to share the same config, so I don't have to keep to update resource names in 2 places.

2) No simple way of templating files. A script that would replace {var} with value of $var in a file seems like an obvious thing for shell to do for you, but I haven't found a good way of doing it.

Post reply on HN