211–220 of 258 posts
Earlier quoted context omitted.
My rule of thumb is to use a real language if there is more than one if fi block.
So, what in your opinion constitutes a "real language", and why?
Earlier quoted context omitted.
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…
Why? No external dependencies, your code can run anywhere you have a Bash shell. This also means a smaller attack surface. Also readability: While some of the examples may be somewhat confusing to someone who doesn't have a lot of Bash experience, to someone who does it can be a lot more readable then feeding a string in yet another language to an external program and processing the output..
Earlier quoted context omitted.
But if I write the script for a bunch of RHEL servers then OS X and brew are irrelevant, and the full path is better (IMHO). It's the 'always use env..' I object to.
It's RHEL... today. `/usr/bin/env` is a POSIX standard. Maybe one day, RHEL will put bash in /usr/local/bin. Or maybe you'll switch to FreeBSD one day, and suddenly everything goes boom.
Bash in RHEL is in /usr/bin and /bin as /bin in symlinked to /usr/bin. I think it is equally unlikely that RHEL (Debian, SLES..) will will move either /bin/bash or /usr/bin/env as it would break a million scripts out there.
If we should migrate to FreeBSD while, for some reason, reusing linux oriented bash scripts, changing the path to /usr/local/bin/ would be the least of my headaches.
I agree that 'env' can make good sense if you don't know who/where/when your script is used. For internal projects, I don't really see the advantage.
Earlier quoted context omitted.
I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree. This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some w…
I think tcl is exactly in this niche. I haven't had time or an excuse to learn it, but it seems to fit perfectly. Haven't yet found out why it seems to be dying away
Earlier quoted context omitted.
I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree. This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some w…
I think tcl is exactly in this niche. I haven't had time or an excuse to learn it, but it seems to fit perfectly. Haven't yet found out why it seems to be dying away
Earlier quoted context omitted.
Why? No external dependencies, your code can run anywhere you have a Bash shell. This also means a smaller attack surface. Also readability: While some of the examples may be somewhat confusing to someone who doesn't have a lot of Bash experience, to someone who does it can be a lot more readable then feeding a string in yet another language to an external program and processing the output..
Sed exists everywhere for a reasonably complete definition of everywhere - if it doesn't exist then you probably don't have access to Bash (and definitely not a fully featured one)
Your definition of "reasonably complete" might not work for everyone else's use case.
Earlier quoted context omitted.
I have a personal dislike for "non human readable" used as shorthand for "not immediately and easily readable by me".
I'm not sure you are being fair. I think any frequent user of regex understands how easy it is to produce expressions that are very difficult to parse. I also think that a discussion about readability makes sense in a post about Bash. I don't personally program very often in Lua, Go or Ruby, but for the most part when I encounter code in these languages I don't find it very difficult to understand and modify. In cont…
Earlier quoted context omitted.
I've ran into this decades ago with file servers back. Half a million files, takes too long to do a simple for loop and calling 3rd party processes for awk/sed when I was just using them to format/search text. Breaking it down to just to mosty bash one scripts reduced the run time and ended all pauses.
I was going to argue that it would be better to simply not use a shell for that, but > decades ago Frankly, I can only imagine how the environment then would be. Thinking back with your current experience, what do you think you would have done if you had to fix it again?
I use to make lists first, then process the lists, I still do this sometimes since its faster. If you have to run a query every time, your probably doing it wrong, but for small stuff, everything is so far, I can chain gnu apps and be done. I'm not a programmer, I'm a sysadmin so mostly deal with the fixing things like auditing or fixing data on a file system. (or maybe db)
I have a personal dislike for regexes and non human readable code, it gives maintenance headache. It's why I avoid shell scripts as much as possible. The first example is not human readable, if the name of the function is a lie, I have no idea what this piece of code do : trim_string() { : "${1#"${1%%[![:space:]]*}"}" : "${_%"${_##*[![:space:]]}"}" printf '%s\n' "$_" }
https://www.gnu.org/software/bash/manual/html_node/Shell-Par...
My inner pedant has no comment regarding readability of Bash parameter expansions.
Hello, I'm the author of the Pure Bash Bible. Happy to answer any questions you may have. Here's an example of what bash is capable of: https://github.com/dylanaraps/fff/ (a TUI file manager written in bash)!
The hacks (as a 30+ year sh / ksh / bash user) are indeed Very Cool.