Earlier quoted context omitted.
Interestingly, FreeBSD used to allow for multiple arguments.
Do you know why they stopped?
Shell Style Guide
271–280 of 336 posts
Re: Shell Style Guide
#272Earlier quoted context omitted.
It didn't work because there was no /usr/bin/env in these systems, or because you wanted a bash different from what was found with $PATH to execute? What were these systems?
I think many lightweight container images don’t have /usr/bin/env for example but they all have /bin/sh. Which I think is the best option for portability. /usr/bin/env is not POSIX anymore than /bin/bash etc.
http://manpag.es/RHEL6/1p+env
Mentions that the env command is POSIX, but it doesn't mention the absolute path. Are you saying that /use/bin/env is not POSIX because there is no guarantee that it will be available at that particular path?
Re: Shell Style Guide
#273I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the w…
> I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset
The Bourne Again shell was created in 1989.
That said, the 1980s Unix mindset was not what you clearly think it to be. It was full of Sun workstations, NextStep, Orthodox File Manager clones, Terminals with graphics, GNU Screen, Threaded ReadNews, ...
Re: Shell Style Guide
#274Earlier quoted context omitted.
Perfectly convenient, safe and fast. Pick any two. https://docs.python.org/2/library/subprocess.html I've told developers that if I catch them writing shell scripts in python they must commit a shell script doing the same set of operations. 2x the work usually dissuades from this type of nonsense.
As usual, "it depends." If you have complex logic, it's generally much cleaner to implement in python. (If you told me I had to rewrite a working Python script in shell, I'd probably think you were joking. Talk about nonsense.)
'It depends..' is a quagmire for the unwary.
My route is to make a good rule about writing python with more than 'n' os., subprocess. and *.Popen calls automatically requiring shell script counterparts in case we find your need to pythonize unsafe, unreadable and slow|broken|buggy.
Re: Shell Style Guide
#275Earlier quoted context omitted.
Do you know why they stopped?
https://svnweb.freebsd.org/base?view=revision&revision=14673...
So they did it for compatibility. In the end, it seems better to take everything as 1 argument instead of simply splitting on spaces, without having support for quoting and escaping. That way you can have arbitrary code with spaces in the shebang if that's ever a good idea.
Re: Shell Style Guide
#276> Shell should only be used for small utilities or simple wrapper scripts. Oh you mean we weren’t supposed to write an etl solution in bash?
If it wasn’t a toy project in which the transformation was elementary then no, you probably shouldn’t have.
If it went well for your company in case it wasn’t a toy project then I would say that it was despite bash, not thanks to bash.
Re: Shell Style Guide
#277Earlier quoted context omitted.
I’ve actually seen this happen. It’s terrifying.
You don't know true terror. I've seen an "ETL" solution (minus the "T") written entirely in SQL but using XML instead of tables and columns. After traveling through multiple servers via OpenQuery it eventually gets loaded into a domain-specific piece. That piece passes the data into a frontend that can only run in quirks mode. That frontend has 60-80 separate projects that all parse out basically the same data but fr…
They should have fired the author/s of this abomination much earlier instead of allowing that thing to evolve up to that size.
Re: Shell Style Guide
#278Earlier quoted context omitted.
You don't know true terror. I've seen an "ETL" solution (minus the "T") written entirely in SQL but using XML instead of tables and columns. After traveling through multiple servers via OpenQuery it eventually gets loaded into a domain-specific piece. That piece passes the data into a frontend that can only run in quirks mode. That frontend has 60-80 separate projects that all parse out basically the same data but fr…
Sounds very much like IBM AS400
I’m not sure when you worked on AS/400, but from what I remember there was no xml involved at all, although you had to deal with DB2 and the almost comical table and column names...
Re: Shell Style Guide
#279I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the w…
> no single language is objectively superior to another I would say some languages are objectively superior to other for specific tasks. The problem is that very often the task to solve doesn't exactly fall within the realm of any given programming language and one has to make compromise. As for bash, I use it when I feel it's the best option, but I also think it's the worst programming language that I have to use. I…
Sure, I agree, for specific tasks. Just like a hammer is a better tool than a screw driver for putting nails in a block of wood.
Thats my point. They're tools not lifestyle choices. Learn your tools, know your tools, don't be afraid of other people's tools.
They all, usually, have some sort of value.
I might as well note this too:
I am speaking in broad strokes, you're going to be able to pinhole this as much as you want because of that. I'm simply suggesting that if your immediate reaction to how another organization uses these tools to replace A with B at a certain level is "this is clearly inferior" instead of "well, what can I learn from this" well, there's the problem.
I used to think programmers/computer scientists where open minded people. Then I realized as a whole it tends to be we're only open minded if its within the domain we chose to be most active in
Still far and away better than any other folks I've met, of course, but this is really a community culture problem, which is why I find it so counter productive.
Alternatives to bash? Many do exist. zsh is bash compatible but does implement its own tools and subsets.
If you're looking for something that removes the bash syntax there is powershell, which does run on Linux/macOS now as well:
https://github.com/PowerShell/PowerShell
Then of course, there is oil shell:
https://github.com/oilshell/oil
which is more like a subset of bash (and somewhat close to the idea of stripping away all the legacy stuff)
Then there is xonsh: lets you use python as a basis for most everything
The stalwart fish:
fish shell has alot of niceties and a more object oriented syntax (kind of)
and for the daring there is ergonomica: https://ergonomica.readthedocs.io/en/latest/
which has a lisp like syntax
as does https://github.com/dundalek/closh which uses clojure and its syntax
and i'm sure there are more.
Re: Shell Style Guide
#280Earlier quoted context omitted.
I think many lightweight container images don’t have /usr/bin/env for example but they all have /bin/sh. Which I think is the best option for portability. /usr/bin/env is not POSIX anymore than /bin/bash etc.
http://manpag.es/RHEL6/1p+env Mentions that the env command is POSIX, but it doesn't mention the absolute path. Are you saying that /use/bin/env is not POSIX because there is no guarantee that it will be available at that particular path?
Interestingly enough, not even the path of /bin/sh is guarenteed. From the POSIX:
> Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.
EDIT: I wondered what POSIX recommended to do for any use of the shebang and this is what I found:
> Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed).
Wow.