[HN Gopher] The bash book to rule them all
___________________________________________________________________
The bash book to rule them all
Author : tosh
Score : 181 points
Date : 2023-11-24 14:45 UTC (1 days ago)
(HTM) web link (fabiensanglard.net)
(TXT) w3m dump (fabiensanglard.net)
| asicsp wrote:
| Dupe: https://news.ycombinator.com/item?id=38187450 (the url here
| has `index.html` at the end, so wasn't automatically caught as
| dupe)
| et1337 wrote:
| I answered every one of those questions "yes, but why is this
| even a thing?" Only in shell can something as simple as global
| variables be a "fallacy".
| Already__Taken wrote:
| I feel anyone that really likes bash needs to have a concerted
| effort to learn how powershell works. It's got a lot of failings
| and MS has made deploying things and using them a pain but
| there's some genius in there and specifically the help system is
| categorically better. nushell is having a similar crack at it.
|
| a rising tide lifts all ships but bash is the mooring block.
| taraparo wrote:
| I gave powershell a good try but I believe it sucks. too
| verbose and the syntax is too inconsistent.
|
| trying nushell next, it looks very promising.
| mr_mitm wrote:
| There are short aliases for the most used Cmdlets and tab
| completion takes care of the rest. Type "Get-Process -" and
| then press CTRL-Space for a list of all arguments. That works
| with _any_ Cmdlet. Impossible in bash. PowerShell is one of
| the best ideas to ever come out of Microsoft.
| INGSOCIALITE wrote:
| so one of the best ideas to ever come out of microsoft is
| an attempt to copy the functionality of bash and
| incorporate it into their .net ecosystem? i hardly think
| this is a compliment
| steve1977 wrote:
| It's not like bash (or UNIX shells in general) have
| invented command line interfaces...
| rvdginste wrote:
| I do not understand the "inconsistent" comment either. The
| "verbose" comment I can follow, but since you have tab-
| completion, it does not really matter that much.
|
| The Get-Help command is super useful, with the option to
| show examples (-Examples).
|
| Consistency is encouraged because every PowerShell command
| is the combination of a verb and a noun. The verbs are
| standardised and you can get a list of supported verbs
| using Get-Verb. Nouns are free to choose.
|
| There is also Get-Command which gives you a list of
| available commands in your current shell. You can import
| modules in the shell which will give you access to extra
| commands. Get-Command supports the parameters Module, Verb
| and Noun to filter commands. This allows you to fairly
| easily discover commands that might be usefull to you.
|
| The Get-Alias command will show you what aliases are
| defined in your shell. This can sometimes be confusing as
| some of the default aliases look like Linux/UNIX shell
| commands.
|
| Creating a PowerShell module is also not that hard. When
| defining a PowerShell command, it is for example very easy
| to limit the values for a certain parameter and that in
| turn hooks in into the completion functionality. The
| completion functionality is available out-of-the-box for
| every PowerShell command available, including the ones that
| you create yourself.
|
| My main OS is Linux, but I do work a lot with Windows
| systems (I develop in C#). I've used bash a lot, but I also
| learned PowerShell because that is simply the way to go on
| Windows systems. I like PowerShell, it has a lot of nice
| features and it is easy to work with. I find it a lot
| easier to program extra functionality in a PowerShell
| module compared to defining extra functions in bash. As a
| C# developer, PowerShell basically also gives me access to
| any C# class available by default in .NET. It is even
| simple to load a class from a third-party assembly, and
| even to compile C# code on the fly. In short, I can do
| whatever I want in PowerShell a lot easier than in Bash.
|
| Note that that does not mean that I no longer use Bash. It
| depends. My default shell on linux is bash. When I need a
| one-liner to do something, I will first reach for bash. It
| is only when I need a longer script that I will reach for
| PowerShell. For example, I need to read a json file,
| manipulate the json structures and write the data back out.
| That is something I would do in PowerShell. For a build
| script that is simply a sequence of steps, I would go for
| bash, even if it involves the use of jq for json for
| example. And obviously on Windows, my default shell is
| PowerShell. Even though I have used cygwin/ming before, I
| would not do that if I can avoid it... there is really no
| need to try to run bash or anything else on Windows when
| you have PowerShell.
| chasil wrote:
| The POSIX shell, like the 1988 version of the Korn shell before
| it, is able to operate with minimal memory.
|
| In the case of ksh88, it was able to be compiled into a 64k
| text segment which was the maximum allowed on Microsoft XENIX
| running on an 80286.
|
| This is a place that Powershell cannot go.
| chubot wrote:
| No this doesn't really make sense. Unix shell is "situated in"
| a bunch of native executables (grep, awk, ripgrep, etc.) and
| textual data, while PowerShell is VM-based, with bindings to
| Windows.
|
| If I were doing stuff with Windows registries, I might use
| PowerShell, but I don't. I use Unix.
|
| One is not a substitute for the other -- it's both the language
| AND the "bindings" that count. bash runs on Windows, and
| PowerShell runs on Linux, but you lose a lot of "enviroment" in
| both cases.
|
| I wrote about this distinction here -
| https://www.oilshell.org/blog/2023/06/ysh-design.html - _Oils
| Is Exterior-First (Code, Text, and Structured Data)_
|
| In those terms, I say PowerShell/nushell are "interior-first",
| while bash and OSH/YSH are "exterior-first". It makes a big
| difference when using them.
| forgotpwd16 wrote:
| Believe GP meant it as (not necessarily end up using it due
| to lacking the environment as you said) "check pwsh to see
| how things can be if you think bash is good". Worth noting,
| since you mention that pwsh has bindings only to Windows,
| that it's possible to make Linux-specific cmdlets/bindings in
| fashion similar to your YSH if understood it correctly (that
| is layering an object environment atop the text i/o of Linux
| commands).
| __MatrixMan__ wrote:
| I really like bash. I tried to like powershell. Nushell feels
| much better than powershell to me as it's not overspecialized
| for integration with .Net and it gets many of the shell
| niceties right out of the box (vi mode, simultaneous history
| and file autocomplete).
|
| I think there will always be a place for something like bash
| pipelines, where the handoff is just a bunch of bits. Some work
| is all about discovering the structure of your data: you can't
| have tools that already know it.
|
| But that's not the majority of work these days. Having the
| handoff be just bits is an elegant solution to the tower-of-
| babel problem, but it would probably be ok if we spent more
| time in structured-mode and only leaned into that solution when
| it was specifically called for.
|
| The problem is that there's no intrinsic structure to data,
| just useful fictions. This makes structured-mode necessarily
| opinionated, which means that the ecosystem will always be
| fragmented: bash and zsh are friends. Powershell and nushell
| are rivals.
| ndsipa_pomu wrote:
| Sorry, but powershell is not going to help me manage a bunch of
| linux machines and it doesn't come with all the usual gnu tools
| that I'm used to. I keep thinking that I should do more
| complicated stuff in a proper language, but BASH is just
| positioned as a perfect duck-tape kind of language - it ties
| together a bunch of other tools and I know it's going to
| already be there on any Linux machine that I deal with.
| tempodox wrote:
| Duct tape. Ducks are glueless.
| phkx wrote:
| You might be surprised (as I was), when you consult
| Wikipedia on this topic:
| https://en.m.wikipedia.org/wiki/Duck_tape
| fourthark wrote:
| My whole life, I've been lied to. Thank you.
| mgdlbp wrote:
| Some (topical) amusements: $ echo 25 | pwsh
| -c '$input-replace"\d",{2*"$_"}' 410 $ echo 25
| | perl -pe 's/\d/2*$&/eg' 410
|
| ``` PS> $temp:pwsh_out = 10000 PS>
| /bin/cat /tmp/pwsh_out 10000
|
| ``` $ echo '''' PS> echo ''''
| '
|
| ``` PS> $Y = { param($f) . { param($x) . $x
| $x } { param($y) . $f { param($x) . (. $y $y) $x
| }.GetNewClosure() }.GetNewClosure() } PS> $fac = & $Y {
| param($f) { param($n) $n -lt 2 ? 1 : $n * (. $f ($n - 1))
| }.GetNewClosure() } PS> & $fac 5 120
|
| ``` PS> gv -v|% m*d|% t* gv -v|%
| m*d|% t* PS> &($x={"&(`$x={$x})"})
| &($x={"&(`$x={$x})"}) $ bash $ eval
| ${x='echo eval \${${x@A}}'} eval ${x='echo eval
| \${${x@A}}'}
|
| ```
|
| bilingual pun, .ps1 .pl 1
| 1 {1} {1} end {1} sub {1}
| {end {1}} {sub {1}} &{end {1}} &{sub {1}}
|
| ``` awk -e 'BEGIN { printf "3\n" }'
| perl -e 'BEGIN { printf "3\n" }' ruby -e 'BEGIN {
| printf "3\n" }' pwsh -c 'BEGIN { printf "3\n" }'
|
| ``` $ time ...; time ...; .... real
| 0.00 ... real 0.00 ... real 0.03 ...
| real 0.22 ...
| no_time wrote:
| Powershell for Linux fails the Litmus test of "Is it in the
| Debian community repo"
|
| This means it's either
|
| - Some "Open Core" bullshit with the secret sauce conveniently
| tucked away in some proprietary blob or restrictive license
| submodule
|
| - Has a build process so convoluted and mystery-meat-dependency
| filled it's not worth to bother with.
|
| - Has so many anti features it would require an extensive
| patchset (like ungoogled-chromium) to fix.
|
| So it might be interesting technology, but it's not something
| I'd deploy by default to every server and expect to work in 5
| years time.
| eichin wrote:
| https://github.com/PowerShell/PowerShell/blob/master/LICENSE.
| .. is the MIT license. (Microsoft supplies debs directly
| which may reduce the motivation for Debian to do so.)
|
| Oh, heh, also https://github.com/PowerShell/PowerShell/blob/m
| aster/docs/bu... the build script is written in PowerShell,
| so there's a bootstrapping problem :-) (Debian has solved
| those before of course, but with community sentiment like the
| above maybe noone is motivated to bother.)
| usrbinbash wrote:
| > needs to have a concerted effort to learn how powershell
| works.
|
| Unless I am a windows administrator, my question is: _Why
| should I?_
|
| There is literally ZERO reason for me as an administrator *nix
| machines to ever touch pwsh.
|
| > but there's some genius in there
|
| I am sure there is. But it's buried very well under layers upon
| layers of deep integration with windows and .NET, the attempt
| to shoehorn a character-based shell into working with objects
| somehow, and a syntax that rivals enterprise java in its
| verbosity.
|
| > nd specifically the help system is categorically better
|
| Is it? Why? Man pages, infopages, and `apropos` all exist.
| Individual man pages may be bad, but the system as a whole is
| solid. It also isn't dependent on the shell. All these
| mechanisms are just normal programs that can be executed by any
| shell.
|
| > a rising tide lifts all ships but bash is the mooring block.
|
| What?
| throwawaaarrgh wrote:
| I mean, the man page is the Bash book to rule them all, but it's
| not a fun or light read. If you want to truly understand Bash you
| need to read it.
| skulk wrote:
| I've used bash for the last 10 years but never read the man
| page, probably never even opened it once. Is there some nugget
| of knowledge that I've missed out on by learning it entirely
| from Google searches and Stack Exchange?
| read_if_gay_ wrote:
| Actually, if you _truly, really_ want to understand Bash by
| _my_ personal arbitrary standard, then you must be able to
| produce the entire source code from memory, because _that_ is
| the _real_ book to rule them all. Sure, you might be able to
| navigate your everyday tasks perfectly, but that 's not what
| matters now is it?
| chubot wrote:
| Yeah, I've been deep in the bash manual and source code
| during my work on https://www.oilshell.org, which basically
| reimplements a "cleaned up" spec-driven bash (called OSH).
|
| But I also used bash for 15 years before that, and I hardly
| used the bash manual. I got by with a minimal / sane dialect,
| and I read a few books about Unix, and one about POSIX shell
| (the latter is also "meh").
|
| Now that I've read almost all of the bash manual, I'd say
| it's not really a special document. It's fine, but it's not
| complete, and I wouldn't say it's particularly well written.
| It lacks examples.
|
| --
|
| The main recommendation I have for anyone who wants to learn
| bash is to learn Unix and C. Learning the underlying model
| explains many things, explains the bad error messages, and
| makes it easier to use.
|
| https://www.oilshell.org/blog/2020/04/comics.html - _Three
| Comics For Understanding Unix Shell_
|
| So yeah I don't think "learning shell" or "learning bash" is
| actually a great goal -- it's part of the operating SYSTEM,
| and you want to learn the OS, and its philosophy.
|
| related - https://www.oilshell.org/blog/2021/01/philosophy-
| design.html - _Unix Shell: Philosophy, Design, and FAQs_
|
| --
|
| Probably the most useful part of the bash manual is the
| acknowledgement that there's a lexing design bug with [[ and
| regular expressions.
|
| It's better to make the regex a separate var, like
| pat='[[:digit:]]+' if [[ $mystr ~= $pat ]]; then ...
| fi
|
| ... than to inline it, because bash does funky stuff when you
| inline it. It confuses regex metachars and bash metachars.
|
| It's trying (and failing) to make regexes syntaically part of
| the bash language, but it's better to treat it like Python,
| where Python syntax and regex syntax are separate.
| usrbinbash wrote:
| `man bash` is, hands down and by far, the most accurate and
| complete bash resource.
|
| That doesn't mean it's a pleasant or even good read. It's
| terse, technical and descriptive. It's a users manual, not a
| textbook, and not a tutorial.
|
| But it's complete, explains everything, it's free, comes with
| bash, and is searchable ;-)
|
| I have spent a lot of time in there, usually when debugging
| or extending old shell scripts.
| eichin wrote:
| Usually when I can't find a _simple_ way to do something,
| only a messy /complicated one, I find it worth popping into
| the info file and looking around - as long as you're
| comfortable using bash-specific (vs POSIX) idioms, there's
| often some generalization that helps. (Having said that,
| stack overflow "isn't great until it is", I've found some
| real gems of "can't you just do this?" that vastly simplify
| what I was trying to do by, effectively, doing something else
| entirely.)
|
| That said, I think with bash (and anything with a man page
| more than 5 pages long - "screen" and "lsof" for example)
| it's worth just doing a quick skim of the entire man page
| once every 5 or 10 years - sure, most of it will be "yeah, I
| know that", and a bunch will be "... who asked for that? why
| do we even have that lever?" but there will be a few things
| that fix something that's annoyed you for years, and a few
| things that you'll ignore and then 6 months later you'll say
| "wait, I read something about this" and go back and fix the
| problem.
|
| (Reading the changelogs of your primary tools is also smart,
| and I'll admit I pretty much only do that when looking at
| security changes, or when looking at a weird behaviour change
| between releases and trying to figure out what the intent was
| - not that I recommend that part per se, you just become the
| greybeard everyone comes to with weird questions :-) Most
| recently, bash pipeline tail-exec...)
| throwawaaarrgh wrote:
| There's a reason the man page is 200 pages long with 43,000
| words. There's a lot more there than you imagine, much of it
| subtle.
|
| Once you've read it, you don't need to Google anymore. You
| just open up the man page to the relevant section and see all
| the context, rather than just one answer to one question.
| corethree wrote:
| Wait. Why are you reading the bash man page without fully
| understanding man?
|
| You need to fully understand man before reading the man
| bash page. Here:
|
| https://man7.org/linux/man-pages/man1/man.1.html
|
| but before that are you reading that on chrome? Have you
| read the chrome documentation?
| wrycoder wrote:
| For a more organized read from the authors at GNU, try the
| online version of > info bash
|
| https://www.gnu.org/software/bash/manual/bash.html
| da39a3ee wrote:
| I'm not sure the book is actually about bash specifically, but
| let's talk about shells anyway.
|
| The existence of zsh makes it all a pretty unsatisfactory
| situation currently. (Btw re. my own level I know the answer to
| most of the questions posed in the article).
|
| I'd be fine learning either bash or zsh to an advanced level, but
| learning both to an advanced level sounds bonkers. So I've
| vaguely come to the conclusion that perhaps that means learning
| zsh well as a command line tool, and then limiting ones shell
| scripts to a sane subset of bash that is sufficiently small that
| you don't need to fully know advanced bash. But then, I don't
| actually like learning advanced zsh. It seems like a silly
| language full of completely ad-hoc syntax. Nevertheless, I do use
| zsh as my shell, I think mainly because tab completion is better.
|
| (I went heavily into nushell, but at the moment it's too
| different from what one's colleagues are using so it can only be
| an auxiliary to POSIX shells, and I decided it was a time sink I
| couldn't afford.)
| justaj wrote:
| In order to be sure that your scripts work across most of the
| shells, you can also aim at POSIX compatibility.
| mmh0000 wrote:
| The wooledge bashguide:1: and bashfaq:2: are the best bash
| resources I've ever read.
|
| :1: https://mywiki.wooledge.org/FullBashGuide
|
| :2: https://mywiki.wooledge.org/BashFAQ
| ndsipa_pomu wrote:
| Don't forget to read up on the pitfalls too:
| https://mywiki.wooledge.org/BashPitfalls
|
| However, I would put using ShellCheck as the single most
| important way to improve your shell scripts
| tempodox wrote:
| I love this article. Short and to the point. I'll go get this
| book.
| brunorsini wrote:
| Thanks for the recommendation. In my case, GPT revolutionized the
| way I use bash. If you know what you want to accomplish, gone are
| the days of endlessly fiddling around with syntax.
| steve1977 wrote:
| Until the day when GPT hallucinates some nice (and confident)
| rm -rf equivalent for you ;)
| ykonstant wrote:
| Which is extremely easy to do; just a misplaced `mv` is
| enough. I can't believe people are relying on GPT for ad hoc
| destructive I/O.
| pipes wrote:
| I used chat gpt to explain what a complex line in a bash
| script was doing. Though to be fair if I'd spent a day in
| man pages and Google I'd probably have learned a lot more
| than just being given the answer. Which makes think in the
| long run gpt may result in worse programmers.
| rascul wrote:
| https://explainshell.com/ can help with that but isn't
| perfect.
| Ma8ee wrote:
| In the same way as Stack Overflow has resulted in worse
| programmers, at least in some senses.
|
| I don't mean to bash on SO, it's really valuable
| sometimes. But corporate culture (faster is always
| better) and a new breed of programmers that don't really
| care, have left us with a big part of the profession that
| are unable to produce anything new, or solve any unique
| problems.
| swatcoder wrote:
| And a generation before that, it was VB and (early) PHP
| programmers that earned that critique.
|
| It does feel like the proportions might be changing and
| the quality of software is trending downward, but I think
| you have it right that the risk of programmers being too
| "GPT-reliant" is the continuation of a long,
| intergenerational pattern.
| an_aparallel wrote:
| this is one of my BIGGEST frustrations learning to
| program. i do...not...want....to go online to work out
| hooow to do something. I want a "manual" - written
| well...that i can study and find the write tools to
| use...which for example (Pythons docs...are not...at
| least for beginners) - i then want to use the tools in
| said manual....to create. With the syntax, and the words
| you've defined oh so well in said manual. But...as the
| language grows...we'll just have to live with this never
| happening :)
|
| this is something i get jealous of older programmers who
| grew up on old computers, with printed manuals...when
| languages were smaller, and the scope of programs were
| also smaller...and didnt require external libraries.
| keybored wrote:
| Bash doesn't deserve the brainspace that truly knowing it
| would demand.
| simonw wrote:
| What's better: spending a day figuring out a single line
| of a complex Bash script, or spending that same day
| learning literally 100x more because you didn't have to
| waste that much effort on each individual thing?
|
| For me, the alternative to using ChatGPT to figure some
| weird piece of Bash trivial out isn't doing the work
| myself, meticulously and at great length. It's losing
| interest and not figuring that thing out at all.
| eternityforest wrote:
| Losing interest and not figuring it out at all has been
| my approach to nontrivial bash. I'm not a UNIX philosophy
| fan in general, but trying to bea programming language
| and also a UI, all in one, is a bit much. It's ok-ish as
| a UI for cases where GUI doesn't work or you want a
| machine to be able to use the UI, but as a language it's
| missing a lot of stuff.
| Rediscover wrote:
| Other option: asking the grey beard down the hall how to
| do it. Fifteen minutes, and all parties are happy.
| Analemma_ wrote:
| Have you actually tried it? Because this comment seems
| pretty misplaced with the reality of what ChatGPT can
| accomplish. I also use it all the time for bash one-liners,
| and so far my experience has been "80% work correctly on
| the first try, 15% require minor adjustment to run, 5%
| require major adjustment to run" and so far none have ever
| done anything flagrantly wrong or destructive. It also
| doesn't just print a command with no context: it explains
| what each flag/step of the command is purportedly doing,
| which you can (and should!) use to double-check that what
| you're about to run makes sense. Which is more than I can
| say for a lot of SO answers!
| swatcoder wrote:
| Traditionally, the alternative wasn't "SO answers", which
| are indeed dangerous in their own way -- it was to
| develop, and then maintain, a comprehensive and fluent
| understanding of the tools suitable to your profession.
|
| GPT and SO can help you make a deadline today, and we all
| may use them now and then, but consistently relying on
| them steals essential opportunities for professional
| growth.
|
| A journeyman woodworker who just asked somebody else to
| perform all his tricky jigsaw cuts is going to have a
| hard time developing the muscle memory and intuitions
| that mark mastery of the craft.
| simonw wrote:
| I'd rather get to AI-assisted mastery of many more
| different crafts than limit myself to achieving mastery
| of just one single thing.
| fragmede wrote:
| A master carpenter that only uses hand tools is a master
| of their craft, and should be respected as such, but
| refusing to ever use power tools because of a moral
| objection to electricity would be seen as quite the
| eccentricity. Which, the Amish sell furniture, and it's
| really quite good, if niche, furniture.
| anjanb wrote:
| I've used chatGPT(ver 4 through ChATGPT plus) for
| creating .bat files. Really easy ones, it can churn out
| quite well. A lil more complicated - it doesn't consider
| edge cases. Several cases require me to ask it to
| generate a golang program that gets called by the .bat
| file.
|
| Several times, I had to spend hours to get a .bat script
| working. Hopefully, it will get better in the future.
| cactusfrog wrote:
| It's really useful for learning. "Describe this complex
| bash command I found on stack overflow line-by-line". Write
| a quiz question to make sure I understand it. Rate my
| response to this quiz question.
| arcanemachiner wrote:
| > Write a quiz question to make sure I understand it.
| Rate my response to this quiz question.
|
| I like this idea. Definitely gonna steal it.
|
| I love that "extensions" can be implemented just by
| writing a couple extra words.
| dotancohen wrote:
| This is what I come to HN for. I'll see if ChatGPT could
| maybe generate some relevant Anki cards as well.
| arcanemachiner wrote:
| There's a big difference between "build this program for
| me" and "explain how this line of bash code works".
|
| I use LLMs for the latter, and they often do a great job
| and save a lot of time looking up individual flags,
| concepts, etc.
| Too wrote:
| Both could be equally wrong and hallucinated.
| thedaly wrote:
| > Both could be equally wrong and hallucinated.
|
| As can I. I recently broke my years long streak of not
| deleting something by accident with an errant bash
| command.
|
| Just because a tool has the potential for a negative
| outcome doesn't mean it shouldn't be used. It just means
| appropriate caution should be used as well.
| williamcotton wrote:
| This statement implies that LLM hallucinations are
| completely random which is objectively false.
|
| LLMs fill in the blanks when left to synthesize a
| response from a prompt as opposed to translating a
| response from a prompt. These synthesized responses, aka
| hallucinations, are predictable in nature. Quotes, titles
| of books, web page links, etc.
|
| Conversely, providing an LLM with all of the facts
| necessary to complete a response will result in few to no
| hallucinations.
|
| For example:
|
| Select name and row_id from table1 joined on table2 on
| table1_id.
|
| This will never return "DROP table1;". It will basically
| only ever return something very close to what you want.
| AlecSchueler wrote:
| I haven't tried GPT for this purpose but I don't think we
| need to assume that everyone tinkering with it are blindly
| copy pasting potentially destructive commands.
|
| Anyone who does that now would already have done it from
| random Google results anyway.
| anjanb wrote:
| It shouldn't be too difficult to pipe chatgpt output to bard
| or something equivalent and ask for validation
| spion wrote:
| You can also (surprisingly) ask ChatGPT for validation. The
| part of the LLM that activates when solving problems is
| going to be different than the one that activates when
| reviewing.
| da39a3ee wrote:
| Not used GPT much?
| Timpy wrote:
| For me bash is a weird exception to the rule "code is easier
| to write than it is read". I'm never doing anything crazy in
| a shell a script but it's easy to just ask ChatGPT to whip it
| up for me and I will read it to verify. Perhaps anybody who
| can't validate the output is just as likely to write an
| accidentally-destructive script the old fashioned way.
| tovej wrote:
| Good luck with that, hope you never have to write a portable
| shell script
| markstos wrote:
| There's a method that's even faster than asking ChatGPT what to
| type, and that's knowing what to type.
|
| For tasks you do regularly, it's worth the investment to learn.
| kstrauser wrote:
| I agree. Here it's being used like a translation app: convert
| English into the shell language. That's all well and good for
| a place you're going to visit a couple of times, but if you
| plan on living there, you need to learn the local language.
| AlecSchueler wrote:
| Being able to use a tool akin to Google translate is a
| fantastic boon to language learning though.
| _fizz_buzz_ wrote:
| True, but we cannot possible learn all the things. I wrote a
| nice little batch script last week with the help of ChatGPT.
| This is something I have to do maybe once or twice a year and
| I am sure someone who does this every day was a lot faster,
| but what took me maybe 30 mins would've taken me a day.
| worik wrote:
| Yes.
|
| But there is so much to know one short life
|
| I use Perl, now, for shell scripts. Long before LLMs I
| decided I could not learn another syntax when Perl was 99% as
| good
|
| Same reason I have not learnt Sed and Awk.
| thrwlol wrote:
| You really should compare your typing speed with chatgpt if
| you think you can out type it for a question that you know.
|
| Once I write the document string of the function I want it
| gets it right faster than anyone I know.
| corethree wrote:
| I like this method. The problem with it is that there's just
| too much stuff to know. So let me teach you another method.
| Don't try to know everything, learn to get things from other
| resources, one of which is chatGPT. Worth the investment to
| be wise about what you pick and choose to learn.
| RichardCA wrote:
| Just last week I was asked to provide some possible screening
| questions to recruit for a Devops role. I figured this would be
| good:
|
| "How do you pass a parameter to a Bash script so that the
| script will exit with an error if it's not passed?"
|
| I ran this through ChatGPT and I could not get it to give
| ${1:?} or any variation of that syntax as an answer. So now I
| also have a way to filter candidates who are leaning on the LLM
| during the interview process.
| zatkin wrote:
| Thanks for the tip, I now know that I can't use ChatGPT when
| I'm being interviewed with this question.
| Karellen wrote:
| Is this for an in-person interview?
|
| Because without checking `man` or stackoverflow (or leaning
| on ChatGTP) my first response would be to go with `if [ $#
| -lt 1 ]; ...`. This has the advantage of being pretty
| readable, and while I've been doing shell scripting for long
| enough to consider myself reasonably competent at it, I'd
| have to refer to the man page to be sure what `${1:?}` did.
| stracer wrote:
| That's an unwise way to filter out candidates. It's an
| obscure and unimportant syntax feature whose effect can be
| accomplished in many other, more readable ways. Writing line
| noise using obscure syntax is not a sign of a good
| programmer. If you want to find good candidates, give them an
| assignment in bash and make them explain their solution.
| simonw wrote:
| I said "Give me the most succinct possible idiom" and it gave
| me the answer you were looking for:
| https://chat.openai.com/share/05a3d1aa-
| cd60-40a1-b6d5-ec0c9f...
| mgdlbp wrote:
| The first answer is wrong, and so is the second
| explanation... twice it conflates unset with null/empty.
| Very illustrative!
|
| The substance of the first answer:
| #!/bin/bash # Check if the first parameter
| is not provided if [ -z "$1" ]; then
| echo "Error: Parameter not provided." exit 1
| fi
|
| The snippet precedes the true statement:
|
| > This checks if the first parameter (`$1`) is empty.
|
| But what happened to the supplied task? It was stated and
| echoed as:
|
| > _Anonymous:_ ...if it 's not passed?
|
| > _ChatGPT:_ ...if a specific parameter is not passed...
|
| > _ChatGPT:_ ...if the parameter is set.
|
| The second answer: #!/bin/bash :
| ${1?"Error: Parameter not provided"}
|
| This is correct. But the explanation is not.
|
| > ...and the `${1?...}` part checks if the first positional
| parameter (`$1`) is unset or null.
|
| --
|
| (the most succinct possible idiom is `#!/bin/bash -u`)
| mmh0000 wrote:
| I am very proficient in Bash. My day job is as a Senior
| DevOps engineer. If I were doing an interview and was asked
| that question, I would never give the answer `${1:?}` (if I
| even remember at the time that it existed) because it is
| terrible code. It is obscure and unreadable.
|
| The goal of a DevOps engineer should be to write maintainable
| code so that a junior can come in and tell what it does
| immediately.
|
| As another commenter said, my answer would be: `[[ $# -ne 1
| ]] && exit 1`. That's readable and understandable to anyone
| who has a basic understanding of bash scripting.
| ulizzle wrote:
| What's a good useful difference between .bashrc and .bashprofile?
| I usually just ignore everything but the rc files.
| usrbinbash wrote:
| A shell can be interactive or non-interactive (eg. shell-
| scripts).
|
| An interactive shell can be a login-shell or a non-login-shell.
| A login-shell is what you get when you login at one of the
| virtual terminals of a linux machine. A non-login-shell is a
| shell started after you logged in (eg. clicking your console-
| icon in a graphical desktop environment).
|
| An interactive bash will read and execute `bash_profile`
| (Actually, it will try to read `profile` first, for historic
| reasons) when it is a login shell, and `bashrc` when it is not.
|
| However, the difference is moot on most systems, since this is
| what you will probably find in most `~/.bash_profile` files
| these days: [[ -f ~/.bashrc ]] && . ~/.bashrc
|
| aka. all interactive shells, no matter if they are or aren't a
| login shell will just read `.bashrc`
|
| For completeness sake: A shell run via `sshd` is _technically_
| not an interactive shell, as it is started by the ssh-daemon.
| However, bash behaves like an interactive non-login shell in
| this case and reads `bashrc`.
|
| Also for completeness sake: All the files mentioned can be
| system-wide under `/etc/FILENAME` and user specific
| (`~/.FILENAME`). Bash first reads the files in `/etc`.
|
| The behavior is documented in the manpage `man bash`, under the
| section `INVOCATION`.
| lloeki wrote:
| > An interactive shell can be a login-shell or a non-login-
| shell.
|
| A shell can be login and non-interactive.
|
| This happens e.g when starting a session from a X session
| manager. Subsequently a terminal such as Xterm starts non-
| login interactive sessions, inherits stuff like env vars like
| PATH from the login shell, and is only concerned with setting
| up the additional interactive stuff.
|
| Similarly doing ssh <host> <command> starts a non-interactive
| login shell.
|
| > However, bash behaves like an interactive non-login shell
| in this case and reads `bashrc`.
|
| IIRC nope: distros such as Debian often have bashrc source
| bash profile (or the other way around, I can't recall) which
| has me irate to no end+. They even have some TTY dependent
| stuff in profile which spits out some error in some cases
| when no TTY is allocated because heh not interactive.
|
| + I took great length to have my rc and profile properly
| separated because it's that much faster not to source the
| unneeded stuff (at the cost of having to logout to apply
| login stuff) https://github.com/lloeki/dotfiles
| usrbinbash wrote:
| > Similarly doing ssh <host> <command> starts a non-
| interactive login shell.
|
| Interesting, is there a source for this? Genuinely
| interested, because the manpage leaves this part a bit
| vague: A login shell is one whose first
| character of argument zero is a -, or one started
| with the --login option. (...) Bash
| attempts to determine when it is being run with its
| standard input connected to a network connection,
| as when executed by the historical remote shell
| daemon, usually rshd, or the secure shell daemon sshd.
| If bash determines it is being run non-interactively in
| this fashion, it reads and executes commands from
| ~/.bashrc, if that file exists and is readable.
|
| Sadly, the manpage for sshd also doesn't mention how
| exactly the users shell is invoked. It does say however:
| After this, the client either requests an interactive
| shell or execution of a non-interactive command
|
| ...which I took to understand that the shell dows in fact
| run as an interactive shell.
|
| > IIRC nope: distros such as Debian often have bashrc
| source bash profile
|
| Well, these are distro dependent things. Since I am not on
| Debian, I am just refering to the manpage.
| jbverschoor wrote:
| You can try this out: ssh user@host
| export vs ssh user@host --> export or
| ssh user@host bash --> export
|
| But it's not sshds job to specify how either shell type
| is requested.
| Karellen wrote:
| > A shell run via `sshd` is _technically_ not an interactive
| shell, as it is started by the ssh-daemon.
|
| Hmmm....I'm a bit confused by that one. Why is the program
| that started the shell an important consideration as to
| whether it should be considered interactive or not? Shouldn't
| it just be how the shell is most likely to be used?
|
| Are shells started by `xterm` (and similar) "technically"
| interactive? What about shells started by `screen`/`tmux`?
| What makes them different to, or the same as, `sshd`?
| usrbinbash wrote:
| "Interactive" in this sense has less to do with how the
| shell is used, and more with how it is invoked and
| connected to it's environment.
|
| From the manpage: An interactive shell
| is one started without non-option arguments
| (unless -s is specified) and without the -c option,
| whose standard input and error are both connected
| to terminals (as determined by isatty(3)), or one
| started with the -i option.
|
| Technically, the shell isn't connected to a terminal when
| started by sshd but to the ssh connection. So yeah, from
| the point of view of the user, it is absolutely
| interactive, but not from the point of view of bashs
| internal logic.
| Karellen wrote:
| Huh. My intuition would have been that stdin/stderr
| provided by sshd to the shell would have been been marked
| as `isatty(3)`. TIL.
| rascul wrote:
| This diagram should clear things up in a confusing manner.
|
| https://i.pinimg.com/736x/13/be/5b/13be5b89e662930a2b2dc1573...
| IshKebab wrote:
| I would expect nothing less from Bash. Presumably this is the
| simplified version...
| moffkalast wrote:
| > You want a pretty book with a beautiful Saker falcon
| illustration on the cover?
|
| I don't really get where the trend of making software books with
| animals on the cover originates from, but the parodies are
| fantastic.
|
| https://boyter.org/2016/04/collection-orly-book-covers/
| schoen wrote:
| https://en.wikipedia.org/wiki/O%27Reilly_Media#Early_days
|
| > The original cover art consisted of animal designs developed
| by Edie Freedman because she thought that Unix program names
| sounded like "weird animals".[2]
| youngtaff wrote:
| And if the cover animal is in colour there's colour inside, if
| it's got a black and white animal then there's only black and
| white print inside
| auselen wrote:
| Thanks for this, made my evening!
| tap-snap-or-nap wrote:
| The reason is provided in the last pages of many books that
| they are either endangered or important/keystone species who
| are threatened.
___________________________________________________________________
(page generated 2023-11-25 23:00 UTC)