5 ms·

As much as i love new rust cli tools, `fd` ended up in the same bag as tar and ln.. I can never retain how to use it. I don't blame anybody .. I'm just witness

As much as i love new rust cli tools, `fd` ended up in the same bag as tar and ln.. I can never retain how to use it. I don't blame anybody .. I'm just witness that I always have to re-read the man from scratch to get anything done. And I'm not a gnu find lover.. with all its idiosyncracies.. somehow it registers better.

School-Cotton 2y ago
If you’re having trouble remembering the order of arguments to ln, remember that it’s the same way around as cp. Worked for me. That is, if before there is something at /some/path but not /another/path , after running ln /some/path /another/path there will be something there (same as cp).
- agumonkey 2y ago
  thanks, i still need to ignore the fact that the link on the right points to the left then
- mturmon 2y ago
  This is what made the “ln” argument order click for me as well. Another piece of this parallel is that (with cp and mv) you can omit naming the destination file - you often just name the directory: cp /other/dir/foo.txt . The corresponding shortcut with ln is not naming the destination at all, and the symlink is created in the working directory: ln -s /other/dir/foo.txt Both of the above are my most common usage patterns, and the abbreviation of the second argument in both helps reinforce the parallel between cp, mv and ln.
- stouset 2y ago
  The one that always trips me up is that `ln` is “dumb” about how it handles the first argument. If the first argument isn’t an absolute path, it must be relative to the second argument, and not to pwd. ln ./foo ./bar/baz ./bar/baz will be a symlink whose literal contents are `./foo` so it will look for foo in the same directory (bar), rather than in bar’s parent directory. This is totally backwards from how other utilities behave. Which is completely understandable if you know what it’s doing under the hood. But it is counterintuitive and surprising.
  - tavianator 2y ago
    At least with GNU coreutils, you can use `-r`/`--relative`
    - stouset 2y ago
      TIL!
  - bbkane 2y ago
    I've never internalized this, so I usually stick to using absolute paths... Not a solution for all problems, but it works for me most of the time.
    - stouset 2y ago
      Absolute paths will break if, for example, the target and source are in the same directory but you move the directory. Sometimes you semantically want absolute paths (I want to symlink a thing to /bin/foo), sometimes you want relative paths (I want to symlink a thing to something in a nested directory).
nottorp 2y ago
> As much as i love new rust cli tools Why would you love them just because they're in rust? I'd like to praise the author of this fd for not having "Rust" all over the web page or in the HN link, actually. The Rust inquisition would get far less pushback if instead of threatening people that god will kill a kitten every time you use a non-kosher programming language, they'd promote software that improves (even opinionated improves, like this fd) on existing tools instead of having its main feature "but it's written in Rust!".
- agumonkey 2y ago
  performance for a start especially in the case of fd, it's way faster than gnu find sorry if that annoys people, but a rust tool starts with a high trust in my mind that it will fly ps: to show i'm not in full fanboy mode, i'm often surprised that fzf, brilliant and performant tool, is written in go, but i know it's not rust :)
  - nottorp 2y ago
    > especially in the case of fd, it's way faster than gnu find ... also the only tool written in Rust that made it to HN lately that does not scream "I'm written in Rust!" everywhere :) It also aims to improve on gnu find, not to reimplement it because it's in a non approved language. It's what the Rust evangelists aren't.
  - alp1n3_eth 2y ago
    Surprisingly, Go is great for CLI tooling. It may not have the insane speed that carefully planned and written Rust does, but it's very easy to write and be performant without even needing to go to great lengths to optimize it. I generally say that anything under 500ms is good for commands that aren't crunching data, and even Python CLI tools can come in under that number without too much effort.
    - bbkane 2y ago
      Unfortunately, Python CLI startup time is correlated with how many files the interpreter has to interpret, which usually takes effort to combat, so larger CLIs that have a lot of functionality and thus files always seem to slow down. The Azure CLI is a good example of this. It's been a year or two since I used it, so maybe it's improved since then, but it used to take a second or two just to run `az --help`, which infuriated me. If you own a slow Python CLI, look into lazily importing libraries instead of unconditionally importing at the top of each Python file. I've seen that help a lot for slow Python CLIs at $DAYJOB
bee_rider 2y ago
For tar, I just remember tar czvf and tar xzvf. Of course, then we get the question, ok, why not use a program that just provides those options? But, I think all the extra functionality of tar is nice to have sitting off there in the background; I’d have to look it up if I actually wanted to use it, but it is all there in the documentation, and nicely compatible with the files produced by my memorized commands.
- sitkack 2y ago
  Fully laden Gnu tar or BSD tar?
  - bee_rider 2y ago
    I guess GNU most likely. On my system, it’s just Ubuntu, and on the server side, it is, I guess, whatever the administrator installed, haha.
  - kiwijamo 2y ago
    Both commands work in either I believe. I've been using both since my FreeBSD days and now I use Debian Linux with no change.
- mitsu_at 2y ago
  Reminded of this xkcd :P https://xkcd.com/1168/ https://xkcd.com/1168/
porridgeraisin 2y ago
> tar I remember only two flags for tar. That's it. tar -x tar -c c for create, x for extract. I use it like so: tar -c src | gzip > src.tar.gz and extracting like curl https://source.code/src.tar.gz | gunzip | tar -x That's all. The core operations taking up only this much headspace leaves the door open to slowly start to retain all its other useful options. For example, -v, which means verbose almost everywhere, thankfully means verbose here too, so I add that when I want verbosity. Similarly, I find it easy to retain -l which lists the contents. I do this quite often for stuff from the internet -- I don't like it when I untargz in ~/Downloads and it untargz's it in the same directory instead of doing everything inside a parent directory (preferably with the same name as the archive) Bonus: separating out the gzip like this makes it easy to remember how to use zstd if you want to, just pipe to zstd instead! "Unix philosophy" and all that. I agree with you about `ln`, I can never seem to remember if it's source or target that comes first.

School-Cotton 2y ago

If you’re having trouble remembering the order of arguments to ln, remember that it’s the same way around as cp. Worked for me. That is, if before there is something at /some/path but not /another/path , after running ln /some/path /another/path there will be something there (same as cp).

agumonkey 2y ago
thanks, i still need to ignore the fact that the link on the right points to the left then
mturmon 2y ago
This is what made the “ln” argument order click for me as well. Another piece of this parallel is that (with cp and mv) you can omit naming the destination file - you often just name the directory: cp /other/dir/foo.txt . The corresponding shortcut with ln is not naming the destination at all, and the symlink is created in the working directory: ln -s /other/dir/foo.txt Both of the above are my most common usage patterns, and the abbreviation of the second argument in both helps reinforce the parallel between cp, mv and ln.
stouset 2y ago
The one that always trips me up is that `ln` is “dumb” about how it handles the first argument. If the first argument isn’t an absolute path, it must be relative to the second argument, and not to pwd. ln ./foo ./bar/baz ./bar/baz will be a symlink whose literal contents are `./foo` so it will look for foo in the same directory (bar), rather than in bar’s parent directory. This is totally backwards from how other utilities behave. Which is completely understandable if you know what it’s doing under the hood. But it is counterintuitive and surprising.
- tavianator 2y ago
  At least with GNU coreutils, you can use `-r`/`--relative`
  - stouset 2y ago
    TIL!
- bbkane 2y ago
  I've never internalized this, so I usually stick to using absolute paths... Not a solution for all problems, but it works for me most of the time.
  - stouset 2y ago
    Absolute paths will break if, for example, the target and source are in the same directory but you move the directory. Sometimes you semantically want absolute paths (I want to symlink a thing to /bin/foo), sometimes you want relative paths (I want to symlink a thing to something in a nested directory).

nottorp 2y ago

> As much as i love new rust cli tools Why would you love them just because they're in rust? I'd like to praise the author of this fd for not having "Rust" all over the web page or in the HN link, actually. The Rust inquisition would get far less pushback if instead of threatening people that god will kill a kitten every time you use a non-kosher programming language, they'd promote software that improves (even opinionated improves, like this fd) on existing tools instead of having its main feature "but it's written in Rust!".

agumonkey 2y ago
performance for a start especially in the case of fd, it's way faster than gnu find sorry if that annoys people, but a rust tool starts with a high trust in my mind that it will fly ps: to show i'm not in full fanboy mode, i'm often surprised that fzf, brilliant and performant tool, is written in go, but i know it's not rust :)
- nottorp 2y ago
  > especially in the case of fd, it's way faster than gnu find ... also the only tool written in Rust that made it to HN lately that does not scream "I'm written in Rust!" everywhere :) It also aims to improve on gnu find, not to reimplement it because it's in a non approved language. It's what the Rust evangelists aren't.
- alp1n3_eth 2y ago
  Surprisingly, Go is great for CLI tooling. It may not have the insane speed that carefully planned and written Rust does, but it's very easy to write and be performant without even needing to go to great lengths to optimize it. I generally say that anything under 500ms is good for commands that aren't crunching data, and even Python CLI tools can come in under that number without too much effort.
  - bbkane 2y ago
    Unfortunately, Python CLI startup time is correlated with how many files the interpreter has to interpret, which usually takes effort to combat, so larger CLIs that have a lot of functionality and thus files always seem to slow down. The Azure CLI is a good example of this. It's been a year or two since I used it, so maybe it's improved since then, but it used to take a second or two just to run `az --help`, which infuriated me. If you own a slow Python CLI, look into lazily importing libraries instead of unconditionally importing at the top of each Python file. I've seen that help a lot for slow Python CLIs at $DAYJOB

bee_rider 2y ago

For tar, I just remember tar czvf and tar xzvf. Of course, then we get the question, ok, why not use a program that just provides those options? But, I think all the extra functionality of tar is nice to have sitting off there in the background; I’d have to look it up if I actually wanted to use it, but it is all there in the documentation, and nicely compatible with the files produced by my memorized commands.

sitkack 2y ago
Fully laden Gnu tar or BSD tar?
- bee_rider 2y ago
  I guess GNU most likely. On my system, it’s just Ubuntu, and on the server side, it is, I guess, whatever the administrator installed, haha.
- kiwijamo 2y ago
  Both commands work in either I believe. I've been using both since my FreeBSD days and now I use Debian Linux with no change.
mitsu_at 2y ago
Reminded of this xkcd :P https://xkcd.com/1168/ https://xkcd.com/1168/

porridgeraisin 2y ago

> tar I remember only two flags for tar. That's it. tar -x tar -c c for create, x for extract. I use it like so: tar -c src | gzip > src.tar.gz and extracting like curl https://source.code/src.tar.gz | gunzip | tar -x That's all. The core operations taking up only this much headspace leaves the door open to slowly start to retain all its other useful options. For example, -v, which means verbose almost everywhere, thankfully means verbose here too, so I add that when I want verbosity. Similarly, I find it easy to retain -l which lists the contents. I do this quite often for stuff from the internet -- I don't like it when I untargz in ~/Downloads and it untargz's it in the same directory instead of doing everything inside a parent directory (preferably with the same name as the archive) Bonus: separating out the gzip like this makes it easy to remember how to use zstd if you want to, just pipe to zstd instead! "Unix philosophy" and all that. I agree with you about `ln`, I can never seem to remember if it's source or target that comes first.