141–148 of 148 posts
Phew! I'm glad I've been hitting the "Happy Case" scenario all these years! Very useful article. And very informative. Summary: Instead of - find . -name *.jpg Use quotes around pattern i.e. find . -name '*.jpg' Edit: Oops, the double-quotes should have been single quotes! Thanks, @lucd. Happy case, like I said!
For a long time (probably since the first time I forgot to quote something and got burned, so around 40 years), I've thought that there should be some mechanism for the shell to pass in information about how each argument came about. For each argument, it would tell the program if it was supplied directly, or came from wildcard expansion. For those from wildcard expansion, it would tell the program what the wildcard…
Quiz; in any directory, full or empty I can run this command $ * and get * What allows me to do this? (the $ is the prompt, not what I typed)
GLOBIGNORE=*; *(){ echo *; } welp
alias \*='set noglob; echo \*'
Earlier quoted context omitted.
I think there is a cottage industry around telling people that they're using the interactive shell wrong. This all started with "useless use of cat", which people still bitch about on Reddit and Twitter on a regular basis, and so whenever someone finds something a little weird about UNIX, they are quick to call a person asking a question about it dumb. I think it might be stockholm syndrome, or a symptom of one's gre…
> Bad design is that find uses \n as the output record separator and that xargs uses \n as the input record separator, but \n can appear in filenames! This design can never work and will always lead to difficult-to-debug problems. So instead of fixing it Perhaps, but it also can't be avoided. Everything can appear in filenames. We want filenames to be able to contain any character. The most high-profile attempt to "f…
Interestingly, I guess nobody has ever died because of a buffer overflow. Therac-25 was integer overflow and bad synchronization (and an open loop control system, which people still love). So I guess it doesn't matter.
Earlier quoted context omitted.
For me, Silver Searcher often fails to find matches in files that 'grep' will, easily. I've not been able to determine why this is, but it happens often enough that I consider SS to be highly unreliable, even if its fast. So, it seems that there are still some issues to be sorted here.
This claim needs adequate proof, please provide an example. Otherwise the HN reader has to assume you made a user error.
As soon as it happens again I'll bring it here as an example, but like I said I stopped using silversearcher because of it getting in my way like that.
Earlier quoted context omitted.
You can't, at least on bash version 5.0.3(1)-release with the default config Ubuntu packages it with. After a lag I get the error `$folder_name$: command not found`
I promise you you can, with a previous particular incantation. Answer to come. PS. the response is not important.
Earlier quoted context omitted.
Tip: get into the habit of using && rather than ; So... > ssh remote 'cd /whatever && tar -cf - someglobpattern' | tar -xvf
Seconded. Here https://apple.stackexchange.com/questions/378942/cant-initia... is an example of what can happen from not checking for errors after a `cd` command. Summary: "sudo find ... -delete" ran in the root directory rather than the intended location, and now the OS is gone (probably along with lots more).
Earlier quoted context omitted.
I promise you you can, with a previous particular incantation. Answer to come. PS. the response is not important.
Oh, I thought you meant in an arbitrary directory. If the first file in sorted order is executable and prints "*" to stdout you could get that.
Your answer almost works; but only if PATH includes the current directory which is unusual.
It does hint at another almost answer ...
mkdir t
cd t
ln -s $(type -p ls)
*