4 ms·
If we are not talking about interactive use then to distribute "robust" scripts, you could use nicer and richer Perl, Python eco-systems. For interactive use,
by d0mine 10y ago
If we are not talking about interactive use then to distribute "robust" scripts, you could use nicer and richer Perl, Python eco-systems.
For interactive use, the conciseness, the human-readability of input/output and the fault-tolerance to unrelated changes in the input/output formats provided by Unix shells are also preferable.
- jjnoakes 10y agoThe motivation for PowerShell was to have something good at both. Why switch contexts when moving from interactive use to coded automation if you don't have to?
- qwertyuiop924 10y agoBecause the requirements change depending on which one you're doing: quick shell automation isn't the same as the kind of automation you'd use perl/python for.
- jjnoakes 10y agoAnd yet most of the time I see bash being used for the same kind of automation that you think is good for perl/python. And not because bash is good, but because it is what people know (since they use it interactively) and because it is installed everywhere. So if someone had a tool that was installed everywhere, and used interactively, that could also be used to create more robust automation tasks, that seems like a win to me.
- qwertyuiop924 10y agoIt depends on how complex the automation is. I'd no doubt use a pipeline in places where you'd use perl/python. As for interactive use and robust automation, Bash isn't as bad as you'd think. The reason I'd go to python is because of script complexity, not lack of robustness.