Skip to content(if available)orjump to list(if available)

Path is a utility for working with paths

Path is a utility for working with paths

14 comments

·April 27, 2025

A recent post here got me thinking about my own personal gripes with OS path handling offerings. So I've basically spent the passed couple of days working on a little project in an attempt to rectify the situation somewhat (in the spirit of cross-platform development). It should also work pretty well with existing tools. Let me know what you think, and feel free to open an issue or a pull-request if you have any problems getting it running it on your system. Enjoy!

Github link: https://github.com/SpyrjaGaldr/path

https://simonsafar.com/2025/path_as_system_call/

https://news.ycombinator.com/item?id=43788728

pimlottc

From the name and description, I expected this to perform operations on file path strings, like convert relative to absolute (and vice versa), expand symlinks, convert unix paths to dos, etc. This is more like a find command.

spyrja

I don't see why it necessarily couldn't, my only question would be if there are really many actual use cases for such things? As far as symlinks go, I suppose being able to expand them (but not following them!) might be somewhat useful. But converting to DOS paths and vice-versa? That just doesn't seem very useful. Nevermind converting to-and-fro relative and absolute paths, I can't even imagine what the point of that would be. But perhaps I'm just not seeing the forest for the trees, as they say.

qrobit

As a rule of thumb I always make paths absolute when handling files in scripts. But then sometimes I need to copy a directory tree relative to $CWD somewhere else, so I convert them back to relative

Fish, being a great shell, provides this via `path` command[0]

[0]: https://fishshell.com/docs/current/cmds/path.html

account-5

I've been finding nushell's `ls` with a where clause is pretty good for this. There's also the `find` command too.

jl6

> for the primary purpose of helping other programs know where to find stuff

Potential footgun to make a program rely on this to locate, say, a shared library (as in one of the examples), if there’s a possibility that someone has smuggled a malware’d version of it into, say, /tmp, since it defaults to searching the root directory.

spyrja

Kind of, but also kind of not. I mean if someone can smuggle a file into some random directory, chances are they have enough access to write directly to the "correct" folder to begin with. Personally I wouldn't execute or otherwise load any sort of executable content from a non-root directory (although certainly there are many people who wouldn't even think twice before doing such a thing). So it really just boils down to having a sane security-policy. Restrict searches with something like "path -d /usr *" and you are guaranteed not to scoop-up something that was world-writable in the first place. In fact in the example given in the README, that is precisely how that would have worked. Both /lib32 and /lib64 are owned by "root" and hence not a concern.

vesinisa

What can this do that standard Unix find can not do?

spyrja

I would say the default behaviour just isn't very ergonomic. Suppressing warnings for example requires piping to /dev/null (whereas `path` supresses permission warnings by default), if you want to limit the number of results you have to pipe the output to another command, getting xargs-like behaviour (obviously), or putting quotes around lines with embedded spaces, there are simply more hoops to jump through. It's much easier to type "path -sf .jpg .jpeg .png" than whatever would be required to get the `find` utility to do the same. (Or, say, finding all node_modules folders with "path -z n_m", it's just so much more satisfying.) But yes, these are mostly just syntactic-sugar kinds of issues. Aside from that (and perhaps the lack of cross-platform compatibility), I would say there is nothing inherently deficient about the `find` command. It's a work-horse which probably has more features than `path` does. But the latter really is growing on me. It is actually quite fun to use, if I may say so myself!

jimbokun

“A more ergonomic find command” is a nice elevator pitch.

autobodie

cross platform support, according to the description.

indemnity

spyrja

Looks like it has a pretty good interface as well. It does however seem a just a bit too top-heavy (lot's of dependencies) not to mention a few more bugs than I particularly care for. But sheesh, 37K stars, it must be good for something!

null

[deleted]