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

221–230 of 258 posts

Re: Pure Bash Bible

#221

Post by jascii »

dec0dedab0de wrote: post #211
jascii wrote: post #203

Earlier quoted context omitted.

So, what in your opinion constitutes a "real language", and why?

a "real language" would be any programming language that is primarily designed and presented as a programming language.

Nice recursive definition..

The practice of programming in shell languages was well established when Bash was designed and Bash was definitely designed with that use in mind. So by your definition Bash is a "real" programming language.

Lisp on the other hand, was much more designed as a system and formal notation to reason about certain classes of logic problems.. So, Lisp is not a "real" language?

Re: Pure Bash Bible

#223

Post by dredmorbius »

jbrnh wrote: post #75

I don't quite get the recommendation to always use env bash over #!/bin/bash? If I use the full path, it is to get just that - the system's Bash. If it is missing or overruled in $PATH then I most likely don't want the script to run in the first place.

    $ uname -a
    Linux localhost 3.10.49-5975984 #1 SMP PREEMPT Thu Oct 8 17:25:20 KST 2015 armv7l Android
    $ which env
    /data/data/com.termux/files/usr/bin/env
https://xkcd.com/927/

Re: Pure Bash Bible

#224

Post by dredmorbius »

heuxbzjnz wrote: post #3

no mention of /dev/tcp?! yes, it looks like a device node in /dev, but it's really a pure bashism for opening tcp connections to arbitrary hosts and ports

Keep in mind that major distros (Debian, possibly derivatives) disabled tcp/udp service names in 2000:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65172

Re: Pure Bash Bible

#225

Post by serhart »

pretendscholar wrote: post #182
serhart wrote: post #144

Earlier quoted context omitted.

Yes, but I think that's antithetical to what languages like bash and perl are trying to do. Someone well versed in the language can do some pretty complex operations in a few keystrokes.

which gets back to the original point that these languages have chosen to be more powerful over being more immediately readable. you have to know many more features of the language to understand what is going on compared to colloquially used constructs like if/then or for loops. If you understand english you are a lot closer to understanding the latter rather than the former, more domain specific syntax.

I don't agree at all. I don't find it less "readable". You just have to be used to it. If you understand English, German isn't that hard of a language to learn. Japanese would probably be a little bit harder to pick up though. Doesn't mean Japanese is unreadable

Re: Pure Bash Bible

#226

Post by tracker1 »

mankyd wrote: post #149
jigglesniggle wrote: post #143

Earlier quoted context omitted.

I highly recommend running shellcheck on all of your bash code. It is what finally taught me the practical difference between [[ and [. There are some tests that will always pass in [, for example, but work properly in [[; one project never realized.

My (personal) better recommendation is to avoid bash scripts whenever possible ;) I generally tell people that, once a script is longer than ~100 lines and/or you start adding functions, you're probably better off with something like Python. I know that's not a popular opinion with shell enthusiasts, but it's saved me so much frustration both in writing new scripts and coming back to them later for refactoring.

I tend to work in Windows, Linux and MacOS pretty regularly... so I tend to follow a similar approach (node instead of python though). Windows-isms under msys(git) bash in Windows just gets painful to coordinate at times.

I am curious if people will uptake PowerShell Core (though not much of a fan there either).

Re: Pure Bash Bible

#227

Post by kazinator »

munk-a wrote: post #195
ulysses wrote: post #181

Earlier quoted context omitted.

"A collection of pure bash alternatives to external processes."

It is a neat academic exercise to find these but I think that's sort of the point - why? If you're building something that multiple folks will be reading and using just call out to external processes and make it easier to follow what's going on. It's neat to know how to do these things, but they're honestly a bit of a security hole because a large portion of folks using them will never comprehend the why and how and…

Useful in small embedded. Add twelve lines to a boot script, or bring in several new executables into /bin?

There are resource constraints even in large-ish embedded. Your main file system may live in a decent amount of flash space, but when the kernel is booting, it uses a tiny file system in RAM, which is pulled out of an initramfs image. There is a shell there with scripts.

The partition for storing the kernel image (with initramfs, device tree blobs and whatever else) might be pretty tight.

However, because a lot of these snippets depend on Bash extensions, they preclude the use of a smaller, lighter shell.

Re: Pure Bash Bible

#228

Post by serhart »

papito wrote: post #192
serhart wrote: post #122

Earlier quoted context omitted.

Just because you seem to be unfamiliar with bash doesn’t mean it’s unreadable. Almost any language will look cryptic if you don’t know it. That function is mostly just parameter expansion and very common in most bash scripts. I bet if you read the manual you would easily be able to figure it out. You just have to learn the language.

I don't think it's a matter of familiarity. Most of us here have used multiple languages, and I have no problem saying that the Bash syntax is atrocious. "How do we close a statement.... errr. Let's spell it backwards".

How is it not a matter of familiarity? Just because it's not intuitive to you doesn't mean it's bad. I find anything not in an S-expression to be atrocious. Doesn't mean I can't learn and understand "horrible" syntax where I have to separate things with semicolons...

Re: Pure Bash Bible

#229

Post by xelxebar »

munk-a wrote: post #195
ulysses wrote: post #181

Earlier quoted context omitted.

"A collection of pure bash alternatives to external processes."

It is a neat academic exercise to find these but I think that's sort of the point - why? If you're building something that multiple folks will be reading and using just call out to external processes and make it easier to follow what's going on. It's neat to know how to do these things, but they're honestly a bit of a security hole because a large portion of folks using them will never comprehend the why and how and…

Other people mention constrained environments, but tight loops are also a thing. If you know bash's parameter expansion well, it can make it really easy to write a one-liners that speedily process large amounts of output. Setting up and tearing down a whole process (e.g. sed) can cause an order of magnitude slow down, which is significant if you just want something quick and dirty.

Re: Pure Bash Bible

#230

Post by dec0dedab0de »

jascii wrote: post #221
dec0dedab0de wrote: post #211

Earlier quoted context omitted.

a "real language" would be any programming language that is primarily designed and presented as a programming language.

Nice recursive definition.. The practice of programming in shell languages was well established when Bash was designed and Bash was definitely designed with that use in mind. So by your definition Bash is a "real" programming language. Lisp on the other hand, was much more designed as a system and formal notation to reason about certain classes of logic problems.. So, Lisp is not a "real" language?

Bash is primarily a shell, it even has the word shell in its full name.
Post reply on HN