Hacker News Reader

Comment by animal_spirits | Hacker News Reader

It's so it doesn't clash with any project that actually has a functional `agents/` directory

That's just an argument for having a more distinctive name.

Another reason to use a src/ directory for the actual source code.

That won't save you if you want actual example.com/agents/foo routing and an (say, real estate) agents list at example.com/agents.

I feel bad that you're getting downvotes. The reason is that pretty much every modern web stack decouples the URL routing from the source code directory structure these days. It was a nice hack back in the day, but there are so many problems with it no one really does it any more.

Some frameworks (Laravel, NextJS, etc) map from the directory structure to routes, but that's just a mapping rather than actually exposing the directories on the server. You can have /src/agents accessible as /agents. Or you could have /alice/bob/agents accessible through /agents. It's all just build tooling and web server config at the end of the day.

That's my point. Having your code in `/src` doesn't mean some of that code doesn't still have routing at `example.com/agents`. It doesn't have to be a real directory.

A `.agents` directory (or routing pretending to be one) is nice because you are fairly unlikely to ever have user-facing `example.com/.agents` as a URL.

Or accept the fact that we're in 2025 and not follow Unix conventions from when paper and printer ink were expensive and they were printing out listings, and just name the thing "source".

I've gotten used to it, obviously - as someone with a career in IT for 20 years - but /etc & co. annoy me to no end. I know it will never change, I know why it won't change, I know GoboLinux will be just an interesting experiment, but it's still annoying.

we're -> we are

I've -> I have

& -> and

co. -> company

won't -> will not

it's -> it is

What is the point of this? What is this adding to the conversation?

Fun.

upvote

What I took out of it is that we are human, and humans use abbreviations to save time and effort, not because printer ink was expensive in the '70s.

The abbreviations I wrote are unambiguous. When I first learned about Unix, I basically guessed - I assume as most first timers do - that the folder is basically the location of miscellaneous files ("et caetera").

Oh, let alone the fact that a bunch of the abbreviations are utterly non-intuitive to first timers.

/bin - binaries - nobody born after circa 1980 calls them that anymore. Executables, applications, apps, etc.

/boot - from a lame Baron Munchausen joke from 1970. Should probably be /startup.

/dev - dev is SUPER commonly used for "development". Easy enough to solve as /devices.

/home - okish, probably one of the best named that are actually in there. I'm shocked it's not /ho or /hm.

/lib - reasonable. Though these days in the US it might trigger political feelings :-p

/media - new and reasonable.

/mnt - the whole metaphor of "mounting" is... debatable.https://www.neowin.net/forum/topic/144012-unix-sex/

/opt - what does this even do? Optional? Optional WHAT? Absolutely 0 semantic info provided by the name.

Anyway, a lot of people have done this criticism better than me and it's boring at this point.

> The abbreviations I wrote are unambiguous. When I first learned about Unix, I basically guessed

They're completely ambiguous to someone who doesn't speak English.

> /mnt - the whole metaphor of "mounting" is... debatable

What? Have you never heard of mounting a picture on a wall? Mounting an engine? That's the metaphor.

> Anyway, a lot of people have done this criticism better than me and it's boring at this point.

Your original complaint was about "src", suggesting calling it "source", which is still ambiguous by your own standard. Source of what? How is someone going to know what "source" means if they've never heard of booting a computer? Who is the audience for this change?

Some of your suggestions aren't meritless, but your jumping-off point certainly was.

> They're completely ambiguous to someone who doesn't speak English.

The baseline is English and that's life. I'm not a native English speaker.

LOL ROFLMAO

  /usr -> Program Files (hello spaces my old friends, you've come to break my apps again)
  /var -> ProgramData (but no spaces here)
  /home -> Documents and Settings
  /etc -> Control Panel

Spaces break things only in Lnux; Mac and Windows support them since beginning. Why should we write without spaces as if we were in 5th century?

Spaces are avoided on base Linux systems because they're clunky for terminals more than fear of outright breaking things. To the extent spaces there do break things, that also happens on Mac and Windows for the same reasons (hence ProgramData being conspicuously space-less).

    /home -> Users (it's not 1998 anymore)

Have you considered that there are other metrics people are optimizing for nowadays? Perhaps typeability, screen real estate, familiarity/convention, etc.? Do you really want /User Files/Bob's Files/Coding Projects/Python Projects/Bob's Cool Python Library/Source Code/Model Files/SomeObject.py?

Path length is still a thing in MS Windows, so be careful ;)

Depends on the WinAPI used... I still use C:/src instead of C:/Users/MyUser/src for that reason when working in windows all the same though. Too many unixy utils don't leverage the apis with the longer path, not to mention not supporting the internal certificate store and proxy config.

1. Yes, I have, if you re-read my comment.

2. I don't want to fight extreme positions which I did not make. Read this:

https://gobolinux.org/at_a_glance.html

I didn't say paths have to have spaces, etc. Just be reasonable and <<use full words in the year of our lord 2025>>.

The first shell listing starts with `cd` and `ls`, the former being run in `~`. What does that weird `~` mean? Very strange.

More seriously, their file system is still case-sensitive, and inside /Programs they have `Iptables` and `Fontconfig`, naively capitalized, but also `OpenOffice` and `HTTPD`.

Not to mention that inside each program folder are `man` and `bin` as usual. I'm going to suggest the point of that article is structure and organization, not naming.

Nobody reasonable complains about a three-letter abbreviation you can type with one hand. For a path you're either accessing a lot or never at all, it makes complete sense.

Anything with a capital letter requires hitting two keys: Shift and then the desired letter. Thus /Programs requires 10 keystrokes rather than 9. Even worse, since the capital letter is at the beginning of the directory name, I have to type it and am unable to rely on tab-completion.

/Programs with its ten keystrokes is over twice the keystrokes of /bin and its four. Short names are quicker to type and require less effort. Given that to a first approximation I spend my entire life typing on a keyboard, I very much wish to optimise that experience.

That's really more the fault of the tab completion. There's no reason why it couldn't complete `prog` to `Programs`. It's just Unix tradition that they don't. I would prefer if they did.

In ~/.inputrc, add

    set completion-ignore-case on

to enable case insensitive tab completion in bash.

Great tip! Apparently that's readline's config file, so this will affect a lot of things. That's great news for me; after switching to zsh I got used to case-insensitive tab completion, and now it annoys me when other tools don't work that way. This should help a lot.

Your problem is solved by naming the thing /programs, instead. End of the world using full words, I tell ya!

I think paths need to have emojis too in order to represent the emotional state of the person who created them in the year of our memelord 2025.

What's wrong with spaces? Macs support them since 80s. The only problem with spaces is caused by *nix, *nix shells, basically by Linux.

While we're at this, let's make it rich text please. I want the important filenames to be in bold italic Comic Sans MS.

Call it whatever you like. I don't care and that clearly wasn't the point of my comment.

One thing I've learnt, though, is unless you have a very good reason to try to change language you should just talk the same language as everyone else. I don't like the American short billion. It makes no sense and it's less useful. But that's what I use because I speak English and that's what we use now. If I see a src/ directory I know exactly what it is. If I see source/ it will give me pause. Get over it IMO.

> If I see a src/ directory I know exactly what it is. If I see source/ it will give me pause.

Pause for what, coffee? How does this even make sense?

What could possibly be inside source/, if not the exact same thing as in src/?

While the meaning of "source" may be intuitively obvious, it's still relatively unfamiliar as "src" is far more prevalent than "source" when referring to source files. While "id est" may be equivalent to "i.e.", you'd still naturally pause when reading text using the former instead of the latter, because the latter is far more prevalent in usage than the former.

    $HOME/accept/the/fact/that/were/in/2025/and/not/follow/unix/conventions/from/when/paper/and/printer/ink/were/expensive/and/they/were/printing/out/listings/and/just/name/the/thing/source/main.c

/Library/System/Applications/Core/Security/Daemons.app/Framework/Version 4.6.2/Let's not go full Apple please.

These files also generally work in a nested fashion, like .gitignore and the like. So you want something that can be injected into the namespace of any directory in your project with relatively low likelihood of conflicts.

How about an underscore instead?

Not exactly (or unclear), .gitignore files combine, much like copilot files with glob or other matching. All the instructions are put into the context

> Agents automatically read the nearest file in the directory tree, so the closest one takes precedence

Fair. I didn't think about that.

Reply on news.ycombinator.com