221 karma · joined July 16, 2021
And in my opinion .ssh and .gnupg are okay since in some contexts, the "XDG variables" haven't been initialized in certain circumstances when using those utilities.
But yeah, I'll have to look into those - maybe there is something I can do to fix that
The trick is to use the XDG Base Dir Spec, only if the old ~/.name location doesn't exist. Old users are happy because it doesn't break compatibility and new users are happy because nobody's dropping 10 sacks of potatoes on their metaphorical doorstep
It doesn't seem like you understand much about the specification? I'd recommend reading it, or at least a short summary I've made available here: https://xdgbasedirectoryspecification.com/
Of course, it doesn't help just to complain about the issue in a void, so I've also submitted like 10 PRs and filed quite a few issues. Projects like pnpm and Poetry took note, and now they comply!
Someone's gotta clean up house, and I don't mind doing the dirty work.
I'd think that technological ability and thought quality would improve in unison. Better thought leads to technological leaps, which potentially lead to better thought.
Being a luddite hardly sounds like a solution. Thought not unlike meditation do have their place, but I believe they help enhance "normal" thought, rather than completely substitute it.
I thought about contributing to asdf, but unfortunately many of my pain points are deeply integrated within the design and architecture of the code itself. For example, since there is a lot of code duplication within plugins, it would be good to create a "plugin API" (I think that has recently been proposed). But that would be very time consuming to implement not just because of the already-existing code, but also because essentially every plugin is its own separate repository, usually maintained by different people. So I'd think it's not too hard to imagine how difficult making broad improvements or changes will be.
There's also the fact that writing (decently) fast and cross-platform Bash codes necessitates an essentially orthogonal coding style, which would be at odds with asdf's coding style. Even though the `REPLY` and `$()` is probably 80% of it, I would also like to take advantage of my `bash-core` and `bash-term` Bash libraries, which really wouldn't be possible in asdf (implementation-wise, that would necessitate the use of my Bash package manager)
For literally everything else, I found myself using it more as a task runner - and Make doesn't do a great job at it. You end up mixing Bash and Make variables, string interpolation, and it becomes really messy, really fast. Not to mention the footguns associated with Make.
I found bake (https://github.com/hyperupcall/bake) to suit my needs (disclaimer: I wrote it). It's literally just a Bash script with all the boilerplate taken care of you - what a task runner is meant to be imo
- asdf uses way more commands than it needs to. Instead of glob pattern matching for files, it reads the output of `ls` (and _many_ very similar mistakes)
- When running functions, the output tends to be collected using $(). Since this is done so much, this realllyyyy slows down execution since subshell invocations are slowwww in bash. Better is to set the global variable `REPLY` and use that directly from the callee
- The command line interface is kind of verbise and clunky and a little unintuitive
- There are too many separate plugins to use and download. Too much code duplication between plugins
I hope this doesn't sound like a laundry list of gripes, but just things to improve upon for the maintainers - I understand how hard it is to write Bash that works everywhere. Personally, I've opted to build my own (partial) solution that implements these suggestions at https://github.com/hyperupcall/woof, but my hope is that asdf will become substantially better over the years
I definitely agree, although I've found Please (please.build) to potentially be a solution in this area. It is a lot simpler, smaller, and more modern than Buck and Bazel, but shares similar properties as to be familiar (I.e. the buildfile syntax). I think it is supposed to be easier to extend with other languages, but I haven't tries that myself.
And as the Guide itself, it is mostly OK, but there are a few things I really don't like. For example:
- Whatever doc format they use is not as nice to use as shdoc. Namely, you don't have to add the spaces to your comment to make it formatted properly
- The 'no tabs' thing is pretty bullshit - Bash is literally the perfect language to use tabs and their "Whatever you do, don’t use tabs" comment really kills me
- I don't like their recommendation of using `[[`. Only using `[[` for stuff like regex and glob matching makes it much easier to paste code between Bash and POSIX sh.
There are also a few things they forgot to mention, like the lastpipe` shopt option when talking about piping while loops. And maybe it would be nice to recommend using local like `local var=`. But I guess this guide is meant more for new people that don't know all the pitfalls and stuff
But I think I agree there is some need for a more extensible linter. I've been eyeing the Bash LSP, which is based off the Bash Tree Sitter parser, but that has quite a few bugs with parsing that I've been meaning to send PR's for.
I wonder if `shfmt` has gotten better since I used it. A few years ago, it was quite buggy with prepending extra whitespace whenever I formatted the file
It is also too easy to write poor shell scripts. It is too easy, even for experienced developers to sneak in GNUisms, and forget simple facts, like how Bash and especially Perl aren't guaranteed to be installed on all systems. Sometimes I also wonder: does Kakoune set `-o pipefail` or `-o errexit`? If somebody sets `ENV` and does something fishy, will that make my text editor unlaunchable? Behavior rooted in common semantics rather than heavy syntax (Bash, Perl) or micro-languages (Awk, Sed) make the overall experience much more pleasant. Especially if you do something like Neovim (Awesome, etc.) and use Lua for Config so you don't have to reinvent anything
This would be very useful as a fallback - in case something like `socat` isn't installed, this can be used to display some sort of dumbed down version of the site
However, I would realllyyy not want to have a more verbose regex dialect. For me at least, it would make recognizing common regex patterns a lot harder since they won't be succinct. It would also be yet _another_ regex variety that I would have to remember.
For me, Perl's DEFINE feature and 'x' switch are definitely close enough[1] to variables and comments. Pardon, I don't remember what they are officially called. What we really need is for more non PCRE engines to implement these features
While I do agree that it would be nice to be able to have 'local' functions and have inter-function cleanup work better, the logical conclusion for me was not to use function subshells. Since the use case is for larger programs (where different functions may want to have their own cleanup mechanisms), I'm opting to go for more of a library route. For example, I'm working on a Bash library that includes a function to allow different sources to add (and remove) functions to the same `TRAP`. A similar function may be useful, possibly involving the `RETURN` trap and the `-T` flag for the use case the author brings up. Obviously, using a package manager for _Bash_ of all languages brings in a lot of overhead, but I think it can be quite powerful, especially with a potential "Bundle" feature that makes scripts work without the package manager.
Concerning specifically the use of subshells, (as other commenters have pointed out) it significantly reduces performance. I also disagree that dynamic scoping is necessarily bad for Bash. I find it quite useful when I need to use various common functions to manipulate a variable - since modifying and 'returning' variables from a function is usually either slow or verbose with Bash. Admittedly though, this feature is quite annoying at times - for example, most public functions in my Bash package manager[2] all have their variables prefixed with two underscores - because they `source` all the shell scripts of all package dependencies - so I want to be extra certain nothing weird happens
[1] https://github.com/hyperupcall/bash-core/blob/a17ab0a8b6070f...
[2] https://github.com/hyperupcall/basalt/blob/main/pkg/lib/publ...