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

81–89 of 89 posts

Re: The Bash Hackers Wiki

#81

Post by laumars »

tannhaeuser wrote: post #44
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.

dash is shipped as a replacement for the Bourne shell, not bash. Thus Ubuntu does also ship bash too.

Alpine doesn't have bash installed. It alsonpretty common not to have bash as part of the base image on non-Linux systems too. You've already mentioned macOS but the same is true for many of the BSDs.

Re: The Bash Hackers Wiki

#82

Post by kyuudou »

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…

I think the biggest distinction between shells is whether they are C-shell derivative (csh/tcsh) or Bourne shell derivative (sh/ksh/bash).

Re: The Bash Hackers Wiki

#83

Post by orf »

vaingloriole wrote: post #62
epr wrote: 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.

Balderdash and hokum. z=1 ; while test ${z} -lt 4 ; do a=${RANDOM:1:3} ; dd if=/dev/urandom count=12 bs=4 of=${a} && b=$(cat ${a}) && echo ${b:$(expr 1 + ${RANDOM} % 4):12} ; ((z++)); done You have one tool that you know well. I have thousands of tools that I've learned daily and I wrap with a bash script..except when I need python/tcl or C. Most of what I do in python/tcl/C is truly complicated, needs to be fast or…

Pretty sure it's just this:

> python -c "for i in range(4): print(__import__('os').urandom(12)[__import__('random').randint(1,4):12])"

Or something like it, that bash one liner is pretty unreadable and full of side effects that may or may not be needed. A small 3 line python file would be cleaner and more readable.

Re: The Bash Hackers Wiki

#84

Post by naniwaduni »

lizmat wrote: post #46
chubot wrote: post #17

Earlier quoted context omitted.

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…

"Full support" for Unicode is almost never what you want unless your program literally interacts with font rendering, and then it's not even close to enough. Most of the time the important requirement is that you don't mangle data as it passes through your program, which e.g. early py3 spectacularly failed and is still not better at than py2 in the very common case where your input is not actually necessarily well-formed Unicode, but just an unrestricted byte array that by convention usually contains utf-8.

Most of what people hope for Unicode support to achieve beyond that (case-folding, homoglyph elimination, &c.) is not only not achieved, but not even possible.

Re: The Bash Hackers Wiki

#85

Post by qilo »

orf wrote: post #83
vaingloriole wrote: post #62

Earlier quoted context omitted.

Balderdash and hokum. z=1 ; while test ${z} -lt 4 ; do a=${RANDOM:1:3} ; dd if=/dev/urandom count=12 bs=4 of=${a} && b=$(cat ${a}) && echo ${b:$(expr 1 + ${RANDOM} % 4):12} ; ((z++)); done You have one tool that you know well. I have thousands of tools that I've learned daily and I wrap with a bash script..except when I need python/tcl or C. Most of what I do in python/tcl/C is truly complicated, needs to be fast or…

Pretty sure it's just this: > python -c "for i in range(4): print(__import__('os').urandom(12)[__import__('random').randint(1,4):12])" Or something like it, that bash one liner is pretty unreadable and full of side effects that may or may not be needed. A small 3 line python file would be cleaner and more readable.

TIL about Python __import__ function. Thanks!

Re: The Bash Hackers Wiki

#86

Post by ShorsHammer »

vaingloriole wrote: post #64
ShorsHammer wrote: post #43

Earlier quoted context omitted.

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…

Would never use python in lieu of curl/jq for json handling unless I am writing something more complicated than a shell script. catch 22.

If it gets the job done good on you.

Each to their own. Simply saying what I would look for.

Have any examples of your apt install jq script? How would you install jq on a few hundred machines also?

I'd be happy to share an example of an out of the box python script that does the same job and works virtually everywhere.

Re: The Bash Hackers Wiki

#87

Post by wodenokoto »

laumars wrote: post #79
wodenokoto wrote: post #77

Earlier quoted context omitted.

> just pass environmental variables between applications That would require me to 1) somehow ensure that shell is sourcing the the environment variables from a file, and 2) we are back to all the hackery mentioned in the article [1] [1] https://wiki.bash-hackers.org/howto/conffile

You don't need a shell script to initialise an application with specific environmental variables. systemd and docker will both do this (and both supports the same env file too). AWS lambda supports environmental variables, so does most CI/CD solutions. It's a pretty standard way to do things in UNIX/Linux. In fact if you're having to resort to "hacks" to get environmental variables loaded then that might be a symptom…

Thank you for your patience in answering my woes.

You’ve given me a lot of food for thought and some good ideas on how to attack some of my problems.

Re: The Bash Hackers Wiki

#88

Post by Grinnz »

chubot wrote: post #74
lizmat wrote: post #46

Earlier quoted context omitted.

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

Oil has better Unicode support than Python 2 or 3 for shell-like tasks, because of the way file systems, libc, and the kernel work. Explained here: http://www.oilshell.org/blog/2018/03/04.html#faq which links: http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ (by Armin Ronacher) The summary is that there are two kinds of Unicode support: - UTF-8 based: Go, Rust, and Oil (and Perl 5 it seems, not sure about Raku) - array-…

Perl (5) is array-of-codepoint based, at the logical level. Those codepoints might be internally stored as their encoded-to-UTF-8-bytes, or they might not, but this does not affect the usage of the string.

Many don't really understand the string model (because many don't really understand character encoding) but it comes down to: all input and output is going to be bytes, which by default is stored as the codepoints sharing the ordinals of those bytes, and there are several mechanisms by which you can manually or automatically decode/encode those byte ordinals to the represented characters; for most text processing, you do this on STDIN and STDOUT.

Re: The Bash Hackers Wiki

#89

Post by tecleandor »

jtvjan wrote: post #54
Aloha wrote: post #37

Earlier quoted context omitted.

Not installed anywhere by default

Ruby? It's installed by default on Mac OS X and many Linux distributions.

From now on, neither perl, ruby nor python will be installed by default on OS X

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

Post reply on HN