9 ms·

I find it interesting how much harder it is to grok bash/sh/zsh than other languages I’ve learned. Off the top of my head it may be tooling like the lack of lin

I find it interesting how much harder it is to grok bash/sh/zsh than other languages I’ve learned. Off the top of my head it may be tooling like the lack of linting, or maybe it’s just experience as I avoid complexity like the plague when writing bash which sounds like a self fulfilling feedback loop. Gpt does seem to unblock this mental burden a bit which has me excited for its potential when it comes to education/teaching.

geysersam 4y ago
Something about the quoting / unquoting can get really difficult to reason about. I'm rarely exactly sure how the language constructs work, even the for loop and the if statement. The syntax is complex compared to most other languages, and subtle differences can give totally different results. PICK = can you THE=tell the RIGHT=difference\ between WHAY="all of" TODO='these versions?'
- cerved 4y ago
  yes
- Izkata 4y ago
  export YOU_FORGOT='this one' (Hint: it's most similar to your second one)
  - cerved 4y ago
    this has nothing to do with quoting also='another way to pass variables to child scopes' sh -c "echo $also"
    - Izkata 4y ago
      Neither of those are passing variables, those are setting environment variables. Bash (probably most shells?) mixes its variables with environment variables, and "export" is how you promote a bash variable to an environment variable. The inline version (GGP's [THE=tell the] version) sets the environment variable only for that one executable, while an exported one persists. Also I'm guessing you didn't test that, you got the quoting wrong (it prints nothing, the second one should be single quotes) ;)
      - cerved 4y ago
        They are both variables. I just wanted to show how it's different from export no I'm on my mobile so I sure did not, should be sh -c 'echo "$var"'
- xlii 4y ago
  It’s easy to reason. It’s a shell that takes commands first and not designed programming language. I have no idea what 1st would evaluate (guess is that PICK is empty and can is run with you as an arg with PICK as execution context) Second - simple. Run the with THE=tell as execution context. Third - set variable to string containing space using backslash as escape Fourth - set variable to string with interpolation (but also useful when it contains quotes) Fifth - set variable to string sans interpolation (but also could be used to wrap strings with double quotes) There are (at least) 2 rationales for that. First - shell have execution context. You need to be able to set it on command so syntax has to allow this. Dedicated programming languages ignore that because everything is some form of a block. The other thing is actually quite fun. Shell existed before we used displays, so you could have printer connected to input. Imagine creating variable and then getting to “oh boy I need to add white space char” without possibility to do backspace. Escaping was more viable solution. On top of that there are many shells with different APIs. Scripting languages were made so one could work with shell while having stable API and sensible construct units. Sure they either moved forward (like Python) or slipped into oblivion (like Perl), so it’s back for shell scripting for some. But after doing some stuff with AppleScript lately I think it could be worse.

geysersam 4y ago

Something about the quoting / unquoting can get really difficult to reason about. I'm rarely exactly sure how the language constructs work, even the for loop and the if statement. The syntax is complex compared to most other languages, and subtle differences can give totally different results. PICK = can you THE=tell the RIGHT=difference\ between WHAY="all of" TODO='these versions?'

cerved 4y ago
yes
Izkata 4y ago
export YOU_FORGOT='this one' (Hint: it's most similar to your second one)
- cerved 4y ago
  this has nothing to do with quoting also='another way to pass variables to child scopes' sh -c "echo $also"
  - Izkata 4y ago
    Neither of those are passing variables, those are setting environment variables. Bash (probably most shells?) mixes its variables with environment variables, and "export" is how you promote a bash variable to an environment variable. The inline version (GGP's [THE=tell the] version) sets the environment variable only for that one executable, while an exported one persists. Also I'm guessing you didn't test that, you got the quoting wrong (it prints nothing, the second one should be single quotes) ;)
    - cerved 4y ago
      They are both variables. I just wanted to show how it's different from export no I'm on my mobile so I sure did not, should be sh -c 'echo "$var"'
xlii 4y ago
It’s easy to reason. It’s a shell that takes commands first and not designed programming language. I have no idea what 1st would evaluate (guess is that PICK is empty and can is run with you as an arg with PICK as execution context) Second - simple. Run the with THE=tell as execution context. Third - set variable to string containing space using backslash as escape Fourth - set variable to string with interpolation (but also useful when it contains quotes) Fifth - set variable to string sans interpolation (but also could be used to wrap strings with double quotes) There are (at least) 2 rationales for that. First - shell have execution context. You need to be able to set it on command so syntax has to allow this. Dedicated programming languages ignore that because everything is some form of a block. The other thing is actually quite fun. Shell existed before we used displays, so you could have printer connected to input. Imagine creating variable and then getting to “oh boy I need to add white space char” without possibility to do backspace. Escaping was more viable solution. On top of that there are many shells with different APIs. Scripting languages were made so one could work with shell while having stable API and sensible construct units. Sure they either moved forward (like Python) or slipped into oblivion (like Perl), so it’s back for shell scripting for some. But after doing some stuff with AppleScript lately I think it could be worse.