Did you write it or did Claude code slopcoded it for you? Claude is the contributor to all your other repositories. There is a world of difference between "here's a problem that I'm really concerned with and poured all my expertise to solve it" and "I told Claude to fix it for me and now I'm gonna abandon it as soon as I'm done with the HN advertising".
I wrote an bash enumerator because I was sick of xargs
111–120 of 202 posts
Re: I wrote an bash enumerator because I was sick of xargs
#112Did you write it or did Claude code slopcoded it for you? Claude is the contributor to all your other repositories. There is a world of difference between "here's a problem that I'm really concerned with and poured all my expertise to solve it" and "I told Claude to fix it for me and now I'm gonna abandon it as soon as I'm done with the HN advertising".
> There is a world of difference between "here's a problem that I'm really concerned with and poured all my expertise to solve it" and "I told Claude to fix it for me and now I'm gonna abandon it as soon as I'm done with the HN advertising"
Re: I wrote an bash enumerator because I was sick of xargs
#113In this thread: bash experts with arcane knowledge, unintentionally demonstrating how awful bash is. The obvious solution would be to use something more sane, like PowerShell or nushell, but instead old experts will always defend the skills they have honed for years, while criticizing anything that's different.
Switched to Nushell and I am not looking back. I don't see any major reason why we should keep dragging Bash into the twenty first century. Nushell is the first time I feel like I can write complex systems operations in a shell without having to spend either a ton of time in the docs or being at the mercy of an LLM. It is godsend.
I tried to switch to nushell full-time but couldn't stick with it.
Ironically, the main friction point were not old-fashioned tools (which `from ssv` usually handled nicely) but the 'new generation' of core CLI tools like eza or fzf. They have really nice visualizations, but they do not output structured data as a middle step, so all the colours and lines only play havoc with nu's parsing.
Since I need to "ls" a lot more often than I need to do data manipulation, the tools won and I went back to zsh. Still keep nu around for the occasional config/data file wrangling though.
Re: I wrote an bash enumerator because I was sick of xargs
#114In this thread: bash experts with arcane knowledge, unintentionally demonstrating how awful bash is. The obvious solution would be to use something more sane, like PowerShell or nushell, but instead old experts will always defend the skills they have honed for years, while criticizing anything that's different.
You could also say that English is an awful language, because the spelling and the pronunciation have diverged too far. But it's the international lingua franca in most contexts, because it's the international lingua franca in most contexts.
People use Bash as the default shell for scripting, because people use Bash as the default shell for scripting. If you want to replace it, you should pick a winner and discourage the use of alternatives, especially when they are better than Bash. So don't say "use something more sane, like PowerShell or nushell". Say something like "use PowerShell, or Bash if you really have to for legacy purposes, but never use nushell for any reason" instead.
Re: I wrote an bash enumerator because I was sick of xargs
#115One thing with classical UNIX commands, is that you can expect to find them into random computers besides one's own laptop. Not everyone has the luxury to only work with their own computer, or run random software on IT/customer managed systems.
This is why I tend to stick to POSIX shell scripting these days, avoiding even bash. The restriction does make some things too painful, though. Before the latest POSIX revision, certain workflows were comically hard to do (unless you combine sh with... M4). The 2024 revision injects some much-needed sanity, but I am wondering, will random computers have shells compliant with that revision?
Re: I wrote an bash enumerator because I was sick of xargs
#116> Or maybe you pipe into xargs and pray your filenames don’t have spaces… Always use -0. Most gnu utilities support it. It makes them put a null byte after every filename instead of a newline. Completely eliminates the problem of dealing with whitespace in the filenames.
For tools that don't support -0, you can add the NULs yourself without much fuss. It's a one-liner in awk/perl/sed. Very handy.
If you do not have -0 options in your xargs/find, I wonder if you will have those extensions in your awk/sed. Perl is a different story.
Re: I wrote an bash enumerator because I was sick of xargs
#117> Or maybe you pipe into xargs and pray your filenames don’t have spaces… Most of this, if not all, is fixable by adding a `export IFS=$'\n'` to your bashrc. I'm not trying to disregard your project, just point out something that took me years to learn and I currently use extensively to solve this very problem. Perhaps you didn't know about it until now... :)
Try not to do that in an uncontrolled file system. Filenames can and will have newlines, including trailing newlines, because evil people like myself inject them everywhere in our local user folders to keep sysadmins on their toes. Use the (now, finally, POSIX) -0/-print0 options for all file parsing which produces the correct behavior on all UNIX systems.
Re: I wrote an bash enumerator because I was sick of xargs
#118I lol'd, but do you think this is valid?
https://github.com/wallach-game/bashumerate/pull/1/files
to me looks like a right solution, even if I was also tired of writing for loops by hand usually
Re: I wrote an bash enumerator because I was sick of xargs
#119If you want a shell to interact with the results, you can of course just use a (sub)shell. ls -1 ./*.sh | xargs -rd\\n sh -c 'for i in "$@" ; do ... ; done' sh 1. not strictly necessary to use -1 as I believe all common ls detect !isatty(stdout) and produce line-by-line output anyway. 2. xargs -r just doesn't run the command if there's no input, also not strictly necessary but I'm addicted to using it because it's th…
> not strictly necessary to use -1 as I believe all common ls detect !isatty(stdout)
I remember, though from the dim an distant past so it could be a long-fixed bug, this not working in at least one circumstance. I've explicitly included -1 in scripted calls to ls since. Of course we are breaking the best practice rule of not trying to parse the output of ls, so problems are not unexpected…
As a generally thing I like to include directives like this in scripted calls even if they happen by default anyway, because is makes my intent clear: I expect the output to being in simple single-column format and the rest will break if it isn't. I even sometimes go as far as specifying --sort=name if nothing else in the pipeline is going to enforce that.
> as long as your xargs has -0 support
I don't think I've encountered an xargs that doesn't have this support for a long time, though I don't work with embedded stuff so maybe there are cut-down versions out there still in active use for space reasons.
The problem I've hit numerous times is wanting to do something between “find -print0” and “xargs -0” and that something not supporting NUL as the item delimiter.
Re: I wrote an bash enumerator because I was sick of xargs
#120One thing with classical UNIX commands, is that you can expect to find them into random computers besides one's own laptop. Not everyone has the luxury to only work with their own computer, or run random software on IT/customer managed systems.
This is why I tend to stick to POSIX shell scripting these days, avoiding even bash. The restriction does make some things too painful, though. Before the latest POSIX revision, certain workflows were comically hard to do (unless you combine sh with... M4). The 2024 revision injects some much-needed sanity, but I am wondering, will random computers have shells compliant with that revision?
Back in the day, as I mentioned around a few times, I found refuge in XEmacs, coming from the comfy Borland IDEs world.
However, I also had to get comfortable enough with vi, because most customer systems that we would be required to access on a support visit, or remotely, only had ed and vi available.
Even if we nowadays stick with Linux distros instead of UNIX in general, there is still the issue of what is there by default.
Yep POSIX shell scripting can be a bit painful, which is why knowing a bit awk, perl and sed might help as well, as they tend to be available by default.