[HN Gopher] Pure Sh Bible
___________________________________________________________________
Pure Sh Bible
Author : akraker
Score : 153 points
Date : 2023-04-30 19:16 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| galaxyLogic wrote:
| Can you "pipe" these Posix-Shell functions together? I read
| somewhere that Bash-shell functions can be?
| BirAdam wrote:
| Many of them yes.
| lamontcg wrote:
| What is everyone's current favorite one-liner for replacing a
| string in all files that match?
|
| In other words alternative implementations of this:
| ruby -pi -e "gsub(/Net::HTTPServerException/,
| 'Net::HTTPClientException')" {lib,knife}/**/*.rb
| indigodaddy wrote:
| Before clicking, I really thought this was some kind of shell
| command front-end to spit out Bible verses or something. Woops.
| catiopatio wrote:
| For something like that, you'd want to use fortune(1) with a
| Bible fortune file, e.g.
|
| - KJV: https://sourceforge.net/projects/fortunebible/
|
| - NIV: https://github.com/optio50/Bible-NIV-Fortune
| chasil wrote:
| Problems with this advice:
|
| ::looping over a file
|
| The "loop over the contents of a file" entry does not protect
| stdin.
|
| Use an alternate descriptor. while read -r line
| <&9 do printf '%s\n' "$line" done 9< "$file"
|
| Particularly problematic is ssh, that will pass $line to any
| remote command that is able to consume it.
|
| The looped commands will receive stdin of the loop when an
| alternate descriptor is used. I use 9 by habit after reading the
| flock manual page many years ago.
|
| ::EXIT trap
|
| dash will only call the EXIT trap on a normal exit. Add INT (and
| any other signal that you want from "kill -l") if you also want
| to catch abnormal terminations.
|
| Windows busybox sh/bash only catches regular exits, no matter
| what else you add.
| djha-skin wrote:
| Mildly annoyed when people constantly refer to their article as
| the Bible of X. For those of us who are religious, it is in poor
| taste.
| jakear wrote:
| The word "Bible" comes from the greek word "ta biblia", which
| quite literally just means "the books". I don't see any issue.
| burnished wrote:
| Struggling to see it. Think this might just be a you thing?
| Maybe talk to a religious leader in your community, they might
| help you with a different perspective that'll speak to you.
| detrites wrote:
| Well, now you know how not-religious people feel about "their"
| word.
| tpoacher wrote:
| It shouldn't. "Bible" etymologically derives from "book", and
| its meaning denotes an authoritative book, or "the" book on a
| topic.
|
| While it is true that the "Christian Bible" has customarily
| been shortened to just "Bible", in principle it is appropriate
| to call any authoritative book that claims to be "the" book on
| a topic as a "Bible", without necessarily carrying any
| religious connotations.
|
| That's not to say that people might not make that link
| mentally, but technically and etymologically speaking the term
| is not religious. In the same way that some people may no
| longer identify as gay=happy, but if you start getting offended
| about people acting having a "gay old time", then that would
| say more about your sensitivies than about how people choose to
| use the word in different contexts.
| jakear wrote:
| The common phrasing christians use is actually "The Holy
| Bible", with "Holy" being a common word in the bible meaning
| "set apart for God". So "The Holy Bible" is that particular
| "Bible" (book) which has been set apart for God.
|
| In fact, calling it a Holy Bible implies there are Bibles
| which are not Holy. As one would expect, given a bible is
| just a book, in greek.
| jjgreen wrote:
| Fair point
| catiopatio wrote:
| Even as someone who grew up in a very religious household, I am
| still struggling to come up with a "steel-man" argument on your
| behalf.
|
| Can you explain why you believe it is in poor taste?
| comprev wrote:
| How common is the expression "Qur'an of X" instead of Bible?
| burnished wrote:
| What? You appear to be saying nonsense.
| tyingq wrote:
| The "Torah of X" is fairly common.
| einpoklum wrote:
| But in Hebrew, "The Torah" doesn't mean a certain book
| anyway. There are "The five one-part-of-five's of Torah".
| The Torah is like the teachings, or the postulates, or
| the theory. So there's Jehova's Torah, or Torat Hashem;
| but there's also your mother's torah: "Remember, my son,
| your father's Mussar (= mores), and do not abandon your
| mother's Torah (= teachings)".
| tyingq wrote:
| Sure, though the Latin and Greek words that Bible comes
| from don't mean any particular book either.
| detrites wrote:
| I don't know. This is an English-speaking site.
|
| From the Cambridge Dictionary definition of the English
| word "bible":
|
| > a book, magazine, etc. that gives important advice and
| information about a particular subject: _Vogue magazine
| quickly became the bible of fashionable women._
| doublepg23 wrote:
| "The Mecca of X" is common enough. I've said "The Mecca of
| Nerds" to refer to Microcenter on a few occasions.
| BirAdam wrote:
| It may be in poor taste, but from a religious person's point of
| view, quite a bit of the current culture in most western
| nations is in quite poor taste. I understand and sympathize
| with your objection, but I think that those called to faith
| (including myself) need to make peace with secularization and
| do as we are taught: take the road of peace at all times,
| accept without condoning, approach all things with open hands,
| provide a better example, help when help is needed, and be
| willing with the courage of our convictions to testify for
| faith when asked (and only when asked).
| INTPenis wrote:
| If we're going to be purists, sh is a far cry from bash.
|
| /s tongue in cheek, please don't kill me. I love bash and I use
| it often. I love Greg Wooledge's bash guides and all the people
| in #bash@libera.
| chasil wrote:
| I like busybox bash (especially on Windows) which is very much
| not bash.
|
| Busybox bash does not implement arrays, for starters, which is
| a deal breaker for many scripts.
|
| The Windows kernel forks processes about 10x slower than Linux,
| so these tricks have _real_ performance value for POSIX-family
| shells running there.
| _kst_ wrote:
| As far as I can tell, there is no busybox bash.
|
| busybox's built-in shell is ash. There are options to enable
| a few bash-compatible extensions, but there is no "bash"
| applet.
| chasil wrote:
| Try the Windows version on frippery.org.
|
| I see it in the screen capture.
|
| https://frippery.org/busybox/index.html
| arp242 wrote:
| There's an option to install the "bash" applet as a link
| to either ash or hush, the two shells that busybox comes
| with. Turns out that a large number of "bash scripts" use
| no bash-specific features in spite of using "bash" in the
| #!, or only a few bash-specific features like [[ ]].
|
| It's disabled by default, and arguably not a good idea to
| enable it because compatibility is not great as you found
| out. Either way, "busybox bash" doesn't exist: only the
| option to alias ash or hush to bash.
| chasil wrote:
| A major one that I use is:
| ${var//findpattern/replace}
|
| It turns out that busybox equates [[ to [ in the source,
| sidestepping the differences.
| stevenhuang wrote:
| that bash you see is actually a symlink to ash
| chasil wrote:
| Did you download the busybox64.exe binary and execute it?
|
| I'm confident that it is presented. I use this to spray
| SQL to dozens of databases.
| BirAdam wrote:
| You can implement arrays for POSIX shell in POSIX shell by
| changing the input separator to new line, and writing some
| simple helper functions to search for it. It's not the
| prettiest solution but works for many use cases of arrays in
| shell scripts.
| chasil wrote:
| There are _much_ more practical ways to iterate over a list
| than that in dash.
| cduzz wrote:
| I have to take exception to some of this; it's "technically
| correct" but like much of shell, likely full of terrifying edge
| cases that are best avoided.
|
| For instance, using eval to have variables with variable names is
| madness.
|
| $ var="world"
|
| $ eval "hello_$var=value"
|
| $ eval printf '%s\n' "\$hello_$var"
|
| I suppose the fancy business with printf is flexing, but I
| suspect the majority of people scanning documents like this would
| prefer to have examples with echo "${variable%%string_modifier}"
|
| Escape sequences are mostly dependent on you being on a VT102
| compatible terminal; I'm not sure what happens if you're on an
| ASR33 and you send this to it...
|
| I'd consider type checking (is this a float) to be similarly
| cursed witchcraft -- after all I've run into all sorts of
| "floats" that aren't just 123.456 strings...
|
| Overall -- there's a huge range of things shell can do that you
| probably should just avoid. Similarly, even if you can do it in a
| clever shell way (the bit shifting math for instance, or
| extensive string manipulation) should likely be done with
| external tools just because people understand "oh, awk or sed --
| I know this!" instead of "what the hell is this line noise?" If
| you're writing performance optimized shell, well, probably put
| the keyboard down and walk away for a bit and reconsider your
| life choices.
|
| Good doc; I'll probably stick to the man page though.
| throwawaaarrgh wrote:
| Actually, eval, much like global variables (which are maligned
| by "real programmers" everywhere) actually works fine for a
| janky shell script.
|
| Also, don't use echo, use printf. echo has different semantics
| and potential footguns depending on the platform.
| ndsipa_pomu wrote:
| It's well worth learning to use printf instead of echo to avoid
| all the various ways that echo can break or is not well
| defined.
|
| https://mywiki.wooledge.org/BashPitfalls#echo_.24foo
| chasil wrote:
| Here are my scary evals to use basic ANSI/vt220 color.
| N="$(printf '\033[')" x=30 for a in Bl R G Y B M C W
| # 4-bit Black Red Green Yellow Blue Magenta Cyan White do
| eval $a='$N'"'"$(( x))"m'" \
| b$a='$N'"'"$((60+x))"m'" \
| ${a}bg='$N'"'"$((10+x))"m'" \
| b${a}bg='$N'"'"$((70+x))"m'" # bX=bright Xbg=background
| bXbg=brgt bgnd x=$((x+1)) done
| N="${N}0m" printf "$Y${Gbg}I am yellow on
| green.$N\n"
|
| I pasted this into my Android terminal, and it works as
| advertised.
| Linux-Fan wrote:
| > I suppose the fancy business with printf is flexing, but I
| suspect the majority of people scanning documents like this
| would prefer to have examples with echo
| "${variable%%string_modifier}"
|
| POSIX itself contains some interesting notes about `echo` and
| `printf`, e.g. from the `printf` page:
|
| "The printf utility was added to provide functionality that has
| historically been provided by echo. However, due to
| irreconcilable differences in the various versions of echo
| extant, the version has few special features, leaving those to
| this new printf utility, which is based on one in the Ninth
| Edition system."
|
| The behaviour of `echo` is especially inconsistent for escape
| sequences. Often, `echo -e` is used to enable escape sequences
| for it but this is not POSIX compliant.
|
| For any "standards-perferring" shell scripting pages I'd thus
| think `printf` is the right way to present it if only to
| advertise that this builtin exists.
|
| > should likely be done with external tools just because people
| understand "oh, awk or sed -- I know this!" instead of "what
| the hell is this line noise?"
|
| I am not actually sure about this "I know this" part. I think
| many users of AWK only ever use it to do some sort of "access
| the n-th column of input" as in `echo a b c | awk '{ print $2
| }'`. Similar for `sed` which is often only known and used for
| "replace string a by string b in input" use cases.
|
| > If you're writing performance optimized shell, well, probably
| put the keyboard down
|
| There is some difference between performance optimized and
| "hugely inefficient" that can make the difference between a
| task taking minutes vs. a few seconds. It may not seem much but
| shell scripts are often integrated into automated processes
| (think of build environments or system startup tasks) and
| there, seconds quickly accumulate. Whether this is relevant to
| your use case, only you can know.
|
| I found this "Pure Sh Bible" to be highly interesting, but
| there are some places where it has some rough edges and it may
| not show the "best practices" for standard use cases. Still a
| very useful resource.
| cduzz wrote:
| There are a huge variety of things you can do in shell that
| you simply shouldn't. If you're adventuring into a world
| where it matters if there's a newline at the end of your
| output as a result of your script running on noodlebsd or
| ache or freeGum, you've already lost.
|
| Don't play the game. Don't do things where it matters what
| the exact output of echo gives you.
|
| Did you know that you can't put a _null_ into a shell
| variable? You can 't. Also, you shouldn't ever be in a
| position to care. Did you know that you can fiddle with the
| "IFS" to let you parse CSVs? Don't _ever_ do that; it works
| but nobody will ever understand what the hell you did. You
| _can_ make an case statement and evaluate it with eval to
| make your own shell script that writes its own shell scripts.
| Please don 't.
|
| All of these adventures are possible, and work fine, and I've
| done them and come back to the code a decade later and I both
| understand what I was trying to do and the code still works
| across a variety of bourne shell interpreters. Nevertheless,
| these are things that shouldn't be done except to flex.
| palunon wrote:
| > Similar for `sed` which is often only known and used for
| "replace string a by string b in input" use cases.
|
| Sed has at least the vi users who may know ex command from
| the vi command mode. Awk needs to be learned for itself.
| tpoacher wrote:
| Regarding conditional expressions:
|
| I found something neat recently. The coreutils version of `test`
| doesn't have this, and when you use `test`, typically what you're
| using is the coreutils one.
|
| But if you use `builtin test` to force the bash builtin variant
| of `test`, this has a nice `-v` switch, which allows you to check
| if a variable is set.
|
| I found out about this recently when I had to use it in my bash
| argument processing library, to check if an option expecting a
| value had not been provided a value (since checking for an empty
| variable instead would mean that an actual empty string would
| also be ignored). (see here:
| https://git.sr.ht/~tpapastylianou/process_optargs/tree/main/...)
| cde-v wrote:
| [flagged]
| juujian wrote:
| ```bash lstrip() { # Usage: lstrip "string" "pattern" printf
| '%s\n' "${1##$2}" } ```
|
| Got me right at the start. I look this up about once a week. Time
| to put it .bashrc already.
| awaythrow98765 wrote:
| If you are at this level of required complexity as in those
| examples, you should use a proper programming language, not
| shell. Half those snippets fail with spaces in the wrong place,
| newlines, control characters, etc.
|
| I think all such shell "magic" should come with a huge disclaimer
| pointing the user at better alternatives such as perl or python.
| And all snippets should have the necessary caveats on horribly
| broken and dangerous stuff such as "if this variable contains
| anything other than letters, your 'eval' will summon demons" in
| eval "hello_$var=value" and stuff...
| throwawaaarrgh wrote:
| Using a more advanced language just because you find shell
| syntax to be wacky is like using a car to get groceries because
| you find panniers or a backpack to be wacky. It's the use case
| that matters; if you're 60 meters from the store, just use your
| bike, or walk.
|
| There are plenty of cases in which Perl or Python will make
| things _much_ more complicated than 5 lines of spooky-looking
| shell script. Sometimes a little mystical sorcery is what the
| doctor ordered.
| bloopernova wrote:
| Yeah, I'm a diehard bash scripter but even I know to switch to
| Python once the script gets above a certain size/complexity.
|
| I should really just _start_ with Python, but old habits and
| all that.
| orf wrote:
| # Remove all leading white-space.
| trim=${1#${1%%[![:space:]]*}} # Remove all trailing
| white-space. trim=${trim%${trim##*[![:space:]]}}
|
| Your scientists were so preoccupied with whether they could, they
| didn't stop to think if they should
| rmm wrote:
| i dont know about anyone else. but since ChatGPT, my shell game
| is probably the one that is most levelled up.
|
| A lot of things i would either do manually because i had
| forgotten shell programming, or i would have done in a seperate
| pyenv with 2-3 packages i can get done in about 4 minutes.
| darkteflon wrote:
| Same. Shell and glue-scripts in Python. The activation energy
| required is now close to zero.
| dorfwald wrote:
| Dylan is a phenomenon. I feel like most people here would know
| about his projects, though.
| zoover2020 wrote:
| Who are they and why should we know them?
| dorfwald wrote:
| Creator of neofetch.
| sevg wrote:
| And kisslinux.
|
| He seems to have gone off the grid though? Seemingly no
| public GitHub activity since 2021.
| akraker wrote:
| Unfortunately, it seems that he has dropped off the grid.
| Didn't realize this until you mentioned it actually. It's
| really too bad. Not a lot is known about why, but more
| information can be found here: https://www.reddit.com/r/k
| isslinux/comments/lsbz8n/an_update...
___________________________________________________________________
(page generated 2023-04-30 23:00 UTC)