3 ms·

It's really not about data structure or anything like that. The big problem with any large shell script is that it's utterly difficult to do proper error handli

by simias 9y ago

It's really not about data structure or anything like that. The big problem with any large shell script is that it's utterly difficult to do proper error handling. Usually the best you can do is check return values to detect an error and 'exit' immediately, hoping that your "trap" works correctly to clean up behind you. >Python lacks efficient, quick and dirty process control. Yeah, quick and dirty, that's kind of the problem really. It's great for 20-line scripts but it turns into a huge mess for larger projects unless you enforce super strict guidelines and everybody has their doctorate in bash. Python, perl and friends make it harder to spawn 3rd party programs and pipe them together for instance, but it also makes it massively easier to handle errors and give decent diagnostics to the user.

pas 9y ago
> trap I don't have more faith in Python's except than in Bash's trap. If you use 3rd party code or a subprocess, then both are pretty weak compared to something kernel enforced. > makes it massively easier to handle errors and give decent diagnostics to the user. I don't really find that. You have to fight for input/output for subprocesses in Python. Sure, logging is easier in Python/perl/PHP/whatever, than in Bash, but error handling is about the same. You have to do everything manually, and there's no compiler, nor type (or other magical) system, that'd warn you if you have missed something.
- chronial 8y ago
  > You have to do everything manually You are aware that error handling is done via exceptions python?
  - pas 8y ago
    You are aware that there's no compiler, and that you have to write the try-except-finally? I'm talking about how weak guarantees Python gives compared to Bash about the correctness of the program. It's easy to get None-s, it's too easy to forget to handle file not found or lack of permission.
    - xapata 8y ago
      Maybe you should start raising exceptions instead of returning None. I've almost never wanted to have my program do anything but crash upon file not found or permission error.
    - kemitche 8y ago
      For most scripts, handling file not found isn't gonna happen anyway. Often the result is just printing to standard out "hey I couldn't find file X" then bailing. An uncaught exception works well enough for this in many cases, such as build scripts. Same goes for permissions issues and a whole slew of similar scenarios. For many use cases, the lack of forced error checking is a feature. Concrete example: build scripts. As long as the cause of the build failure is clear from the uncaught exception, there's no reason to handle it. I don't need a friendly UI to avoid scaring off non technical users, I just need something that handles the happy path well and crashes with a meaningful stack trace when something unexpected happens.
- simias 8y ago
  Let's be clear, I'm not a huge fan of python or exception-based error handling either but I'll take it any day over... whatever you want to call shell ad-hoc error handling or lack thereof. Trap is not like an exception, it's more like "atexit" or a signal handler. You can't really nest them, you can't really recover from them. So I definitely disagree that error handling is about the same, python's a lot better. >there's no compiler, nor type (or other magical) system, that'd warn you if you have missed something. Well that's the whole static vs. dynamic debate but that's a different story. Use C# or Rust or whatever you feel like if you really can't stand python or scheme. Maybe there's a niche to be filled for statically typed scripting languages, there are no popular ones that I'm aware of. Still, that's besides the point, while I personally prefer static typing like you there's really no contest between dynamic typing and "everything is a string and you can only concatenate them" typing.
dkrikun 8y ago
That's because Python is not a scripting language. Dynamic is not scripting.
_sdegutis 8y ago
I always add ‘set -ex’ to the top of my bash scripts to exit on any non zero top level return code and to print out all statements being run including expanded variables or inner statements.

by simias 9y ago

pas 9y ago

> trap I don't have more faith in Python's except than in Bash's trap. If you use 3rd party code or a subprocess, then both are pretty weak compared to something kernel enforced. > makes it massively easier to handle errors and give decent diagnostics to the user. I don't really find that. You have to fight for input/output for subprocesses in Python. Sure, logging is easier in Python/perl/PHP/whatever, than in Bash, but error handling is about the same. You have to do everything manually, and there's no compiler, nor type (or other magical) system, that'd warn you if you have missed something.

chronial 8y ago
> You have to do everything manually You are aware that error handling is done via exceptions python?
- pas 8y ago
  You are aware that there's no compiler, and that you have to write the try-except-finally? I'm talking about how weak guarantees Python gives compared to Bash about the correctness of the program. It's easy to get None-s, it's too easy to forget to handle file not found or lack of permission.
  - xapata 8y ago
    Maybe you should start raising exceptions instead of returning None. I've almost never wanted to have my program do anything but crash upon file not found or permission error.
  - kemitche 8y ago
    For most scripts, handling file not found isn't gonna happen anyway. Often the result is just printing to standard out "hey I couldn't find file X" then bailing. An uncaught exception works well enough for this in many cases, such as build scripts. Same goes for permissions issues and a whole slew of similar scenarios. For many use cases, the lack of forced error checking is a feature. Concrete example: build scripts. As long as the cause of the build failure is clear from the uncaught exception, there's no reason to handle it. I don't need a friendly UI to avoid scaring off non technical users, I just need something that handles the happy path well and crashes with a meaningful stack trace when something unexpected happens.
simias 8y ago
Let's be clear, I'm not a huge fan of python or exception-based error handling either but I'll take it any day over... whatever you want to call shell ad-hoc error handling or lack thereof. Trap is not like an exception, it's more like "atexit" or a signal handler. You can't really nest them, you can't really recover from them. So I definitely disagree that error handling is about the same, python's a lot better. >there's no compiler, nor type (or other magical) system, that'd warn you if you have missed something. Well that's the whole static vs. dynamic debate but that's a different story. Use C# or Rust or whatever you feel like if you really can't stand python or scheme. Maybe there's a niche to be filled for statically typed scripting languages, there are no popular ones that I'm aware of. Still, that's besides the point, while I personally prefer static typing like you there's really no contest between dynamic typing and "everything is a string and you can only concatenate them" typing.

dkrikun 8y ago

That's because Python is not a scripting language. Dynamic is not scripting.

_sdegutis 8y ago

I always add ‘set -ex’ to the top of my bash scripts to exit on any non zero top level return code and to print out all statements being run including expanded variables or inner statements.