4 ms·

> Quoting is a disaster. It surprises me a bit that, of all things that are a mess in shell, your comment mentions quoting. It’s one of the few things that abs

> Quoting is a disaster. It surprises me a bit that, of all things that are a mess in shell, your comment mentions quoting. It’s one of the few things that absolutely make sense for me in shell scripting. Do you have an example for me where quoting feels messy to you? > My favourite solution is Deno. Easily the best scripting tool for infrastructure tasks at the moment. I don’t think there’s an objectively best technology for everyone. For example, how long-term are your infrastructure tasks? What are the chances your scripts are still going to work in 2 years? 5 years? 10 years? Suppose you’re in a large enterprise embedded project which needs to work for 10 years or more, and the project uses shell scripts for infra tasks. Would you recommend to migrate those to Deno or Python?

IshKebab 2y ago
Yes, this was literally from today: https://programming.dev/post/22539101 https://programming.dev/post/22539101 Turn on shellcheck and you'll realise that nobody could get it right without tool assistance. In programming languages with "standard" quoting (Python, JavaScript, Rust, Go, C, etc.) you don't even really need to think about it. > What are the chances your scripts are still going to work in 2 years? 5 years? 10 years? 100% because I'll maintain them. > Suppose you’re in a large enterprise embedded project which needs to work for 10 years or more, and the project uses shell scripts for infra tasks. Would you recommend to migrate those to Deno or Python? Absolutely yes. In fact the longer you expect it to last the stronger my recommendation would be. A shell script with 10 years of tech debt is a scary prospect.
- Hackbraten 2y ago
  > 100% because I'll maintain them. What happens if you leave the project? Are your teammates going to maintain the scripts? What happens when one day, the Deno package gets updated and the script blows up? What if Deno becomes proprietary and closed source? > A shell script with 10 years of tech debt is a scary prospect. Several well-known executables on some Linux distros are really 20-year-old shell scripts. I haven't really seen them accumulate much tech debt.
zahlman 2y ago
>of all things that are a mess in shell, your comment mentions quoting. It’s one of the few things that absolutely make sense for me in shell scripting. Do you have an example for me where quoting feels messy to you? 1. The distinction that shell languages make between single-quotes and double quotes is unintuitive and not seen in other languages - wherein either they are interchangeable (like Python) or denote a completely separate type (like C and several others influenced by it). 2. I can't backslash-escape a single-quote within a single-quoted string. Single-quoting disables backslash-escapes that were already working outside of strings. I've lost count of the times I tried to input a command and was surprised to get a > continuation prompt because the shell thought I was still inside quotes, and then not had any good idea of how to fix my error on the previous line. 3. I can use backslash escapes in a double-quoted string, but then I'm also stuck with variable interpolations. It's difficult to produce a string that contains a literal double quote, literal dollar sign, literal at sign and literal double quote consecutively. Yes, by itself I can wrap that sequence in single quotes, but that doesn't generalize to contexts where I need more layers of quoting. 4. Really nothing generalizes very well to when you need multiple layers of quoting. 5. Not directly an issue with quoting, but there's implicit concatenation between quoted and non-quoted tokens if there's no space between the quote and the other part. This leads to many situations where you think you've gotten it right but you haven't, and don't notice until you either try to iterate on your script or carefully examine the output. 6. But you have to rely on that confusing behaviour if you need a single-quoted string that contains a literal single quote. It's taken me quite a bit of practice to become able to do anything moderately complex, and I still have to check my notes sometimes. But really the underlying problem is that writing these things creates a demand to have some kind of internal structure within the string, so that parts of it can be further processed. It would be far nicer, for a start, if "interpolate values into the string" were an explicit operator rather than a magical property of double-quoted strings. But the main reason I end up using Python to orchestrate command-line tasks is just so I can have actual tuples or lists of strings and manipulate them on that level instead of at a textual level.

IshKebab 2y ago

Yes, this was literally from today: https://programming.dev/post/22539101 https://programming.dev/post/22539101 Turn on shellcheck and you'll realise that nobody could get it right without tool assistance. In programming languages with "standard" quoting (Python, JavaScript, Rust, Go, C, etc.) you don't even really need to think about it. > What are the chances your scripts are still going to work in 2 years? 5 years? 10 years? 100% because I'll maintain them. > Suppose you’re in a large enterprise embedded project which needs to work for 10 years or more, and the project uses shell scripts for infra tasks. Would you recommend to migrate those to Deno or Python? Absolutely yes. In fact the longer you expect it to last the stronger my recommendation would be. A shell script with 10 years of tech debt is a scary prospect.

Hackbraten 2y ago
> 100% because I'll maintain them. What happens if you leave the project? Are your teammates going to maintain the scripts? What happens when one day, the Deno package gets updated and the script blows up? What if Deno becomes proprietary and closed source? > A shell script with 10 years of tech debt is a scary prospect. Several well-known executables on some Linux distros are really 20-year-old shell scripts. I haven't really seen them accumulate much tech debt.

zahlman 2y ago

>of all things that are a mess in shell, your comment mentions quoting. It’s one of the few things that absolutely make sense for me in shell scripting. Do you have an example for me where quoting feels messy to you? 1. The distinction that shell languages make between single-quotes and double quotes is unintuitive and not seen in other languages - wherein either they are interchangeable (like Python) or denote a completely separate type (like C and several others influenced by it). 2. I can't backslash-escape a single-quote within a single-quoted string. Single-quoting disables backslash-escapes that were already working outside of strings. I've lost count of the times I tried to input a command and was surprised to get a > continuation prompt because the shell thought I was still inside quotes, and then not had any good idea of how to fix my error on the previous line. 3. I can use backslash escapes in a double-quoted string, but then I'm also stuck with variable interpolations. It's difficult to produce a string that contains a literal double quote, literal dollar sign, literal at sign and literal double quote consecutively. Yes, by itself I can wrap that sequence in single quotes, but that doesn't generalize to contexts where I need more layers of quoting. 4. Really nothing generalizes very well to when you need multiple layers of quoting. 5. Not directly an issue with quoting, but there's implicit concatenation between quoted and non-quoted tokens if there's no space between the quote and the other part. This leads to many situations where you think you've gotten it right but you haven't, and don't notice until you either try to iterate on your script or carefully examine the output. 6. But you have to rely on that confusing behaviour if you need a single-quoted string that contains a literal single quote. It's taken me quite a bit of practice to become able to do anything moderately complex, and I still have to check my notes sometimes. But really the underlying problem is that writing these things creates a demand to have some kind of internal structure within the string, so that parts of it can be further processed. It would be far nicer, for a start, if "interpolate values into the string" were an explicit operator rather than a magical property of double-quoted strings. But the main reason I end up using Python to orchestrate command-line tasks is just so I can have actual tuples or lists of strings and manipulate them on that level instead of at a textual level.