26 ms·

Dotfiles being hidden is a UNIXv2 mistake (2012)

324 points by varbhat 4y ago

Rackedup 4y ago
just put them all in ~/configs ... many apps still pollute ~/
jzelinskie 4y ago
Haha, the first comment is of me throwing shade on HN, oh geez. Now I'm curious to read the old HN thread that I thought was so disappointing: https://news.ycombinator.com/item?id=4331855 https://news.ycombinator.com/item?id=4331855
- deleted 4y ago
  [deleted]
throw7 4y ago
Don't worry Rob. Freedesktop.org learned and spammed my home dir with Desktop/Document/Downloads/Music/etc/etc/etc...
- kodah 4y ago
  What Rob is griping about is more analogous to $HOME/.config now, or /var/run for non-user specific stuff.
  - t-3 4y ago
    It's even worse with dotfiles nowadays than before. We have the cluttered "xdg" dotfile directories, and then a bunch of stuff makes random dotfiles/dotdirs in the home directory, and then .profiles/shellrcs/xinits that are basically required. Every single program seems to think you want a scrollback history, a configuration directory, or some random garbage to remind of you of that one time used it.
    - samatman 4y ago
      Complying with the XDG standard seems about as good as a stringly typed OS like Unix can get. Part of which is making sure that the defaults the program chooses may be overridden by consistent environment variables. Programs need some way to persist their own state and configuration, after all. The fact that XDG is more honored in the breach is tiresome, but this can at least be corrected, and it's well enough put together to be a steady-state approach to wrangling dotfiles.
    - deleted 4y ago
      [deleted]
    - nmz 4y ago
      Windows fixed this by just having %APPDATA%, and to me, its a great idea. No .config, no .local, no .share, no .randomfile, each installed program has its directory in hidden directory, and nobody has to know what each directory is for, and sure, this is what ~/.config is for some, but I also see there's some stuff in ~/.local/share and so on. To expand on this, when a program gets installed, it should write its binary location in a file, then if you ever erase it, a doesthisexistanymore $Config/dir/*/symlink | remove_entire_configuration_directory should be run via cron daily. No manual cleanup, ever.
      - kodah 4y ago
        Slight correction here, XDG keys are analogous to Windows standards: https://github.com/adrg/xdg/blob/master/README.md https://github.com/adrg/xdg/blob/master/README.md
- psanford 4y ago
  That is annoying but easily fixed with xdg-user-dirs-update eg: xdg-user-dirs-update --set MUSIC ~/.xdg-user-dir/music
  - jrockway 4y ago
    I had no idea. Excellent tip!
  - UI_at_80x24 4y ago
    My annoyance is that they create any 'helpful' directories. It's just as bad on Windows. "Download", "Pictures", "3D crap", etc.... Nope, fuck that. This is my $home, I'll make it look how I want.
    - alexvoda 4y ago
      You may indeed prefer an empty canvas you have full control over. However, creating these folders by default is actually beneficial to most users. Most users (especially the vast majority that transitioned from Windows) expect these folders to exist. I believe the choice to not create these existed and still exists. Yet either all the distros that made that choice are history or they all made the opposite choice. I can say the same about other choices. I vastly prefer having a TRRS headphone jack and expandable storage on a phone. These do not appear to be priorities for most people.
      - adrusi 4y ago
        The choice not to create these directories basically doesn't exist, because all sorts of software will automatically create them if they don't exist, their creation isn't centrally orchestrated. A while back I was using a minimal i3-based desktop and when I launched transmission-gtk it thought I might want a "Downloads" folder, and would create it whenever it launched, even though it had been configures to download files elsewhere.
        alexvoda 4y ago
- MichaelCollins 4y ago
  I've never seen anybody use these trashy preset directories as intended. Experienced users ignore them or delete them, using their own directory structure instead. Inexperienced users use one of them (usually Downloads or Desktop) while the others are treated as write-sometimes/read-never; e.g. sometimes they accidentally have files saved to those other directories which may as well be that file disappearing into the void never to be seen again. These presets only serve to confuse or at best annoy. These directories were well-intentioned originally but proved to be a huge mistake. They need to go away. (Edit: The above rant applies only to Downloads/Music/Video/etc. I think ~/.config and ~/.local are fine. I have no problem using those as intended, and I've seen plenty of other people using them too.)
  - pdntspa 4y ago
    Windows users use them, Mac users use them, hell even on a fresh profile in Gnome I use them... It is a little weird to see htem on a server OS install though
    - rgovostes 4y ago
      They exist on macOS and Windows but I tend to agree that these directories are not particularly useful for users. Apple software tries to organize files but it's a disaster: iTunes used to download movies to ~/Music/iTunes/iTunes Media/Movies, now TV.app downloads them to ~/Movies/TV/Media/Movies (!), and videos I shoot on my iPhone end up in ~/Pictures.
      - pdntspa 4y ago
        There has always been a tragedy of the commons with these folders, nobody can agree on where a lot of stuff goes. Should my game saves go in Documents? What about Documents/My Games/Publisher? What about %APPDATA%/Publisher? Hell there's even a few in ~/My Games. Every new game, figuring out where the save data went is an adventure and it's cluttered up every folder it touches. And now for whatever reason everyone is being pushed to put user data in %APPDATA%, which I don't consistently remember how to get to without that shortcut. So who knows! I just looked up the save data location for Subnautica and it is (I shit you not): %AppData%\..\LocalLow\Unknown Worlds\Subnautica\Subnautica\SavedGames
- petepete 4y ago
  I like to lowercase mine so bin and projects don't look weirdly out of place. Thankfully it's totally customisable. https://github.com/peteryates/dotfiles/blob/master/xdg/.config/user-dirs.dirs https://github.com/peteryates/dotfiles/blob/master/xdg/.conf...
- jmclnx 4y ago
  I agree, but the OpenBSD did some nice things in regards to ~/Downloads Using unveil() and pledge(), OpenBSD hides many $HOME and system directories from Firefox and chrome. Thus an errant javascript will only see things in ~/Downloads So one nice use for these.
- deleted 4y ago
  [deleted]
LukeShu 4y ago
The code in question: https://github.com/dspinellis/unix-history-repo/commit/389a475ba0445aa2816f84796786568a762a930d#diff-02d9990bf5c5bbe1b4473ff16783b30ec389fff3ffe30189990a48b6cbf72239R120 https://github.com/dspinellis/unix-history-repo/commit/389a4...
- pengaru 4y ago
  Funny. People here are conjecturing why one open codes the comparison instead of calling strcmp() presuming it's C when `ls` was written in assembler where calling a C function like strcmp() is far more onerous (and slow) vs. comparing to an immediate (cmpb, bne).
  - ghayes 4y ago
    To be fair, it doesn’t need to be strcmp since the target is known. It could simply check for a null terminator on the next byte or another dot followed by a null terminator. Surely a few more instructions, but not a complex subroutine call.
  - draw_down 4y ago
    I don’t code in C too much but it seems like it would be pretty simple to check if the next index is a null byte.
- dsQTbR7Y5mRHnZv 4y ago
  And the modern reimplementation: https://github.com/coreutils/coreutils/blob/c7920f2/src/ls.c#L3138 https://github.com/coreutils/coreutils/blob/c7920f2/src/ls.c...
  - Gibbon1 4y ago
    All I have to say looking at that is Absolutely Disgusting.
    - wruza 4y ago
      Not sure why your comment is grey, because ! name[1 + (name[1] == '.')] is an absolutely unnecessary code golf bullshit sitting right there.
hbn 4y ago
That's an interesting history lesson! I always assumed hidden dotfiles was a conscious design decision.
- clysm 4y ago
  It's not a history lesson. It's just baseless conjecture.
kgeist 4y ago
I don't understand how skipping an entry by comparing it with strcmp(name, ".") == 0 turned into name[0] == '.' Is it what really happened (lots of programmers, by mistake, wrote a comparison function which is just plain wrong), or Rob Pike is conjecturing?
- deleted 4y ago
  [deleted]
- laurent123456 4y ago
  He seems to be saying it was a shortcut, so that the line excludes both "." and ".."
- Retr0id 4y ago
  They weren't replacing `strcmp(name, ".")`, they were replacing `strcmp(name, ".") == 0 || strcmp(name, "..") == 0`. It's somewhat easy to see how someone would make this shortcut when programming in C, but they weren't programming in C, they were programming in assembly (as the article describes). It's so much simpler to only check the first char when programming in assembly, so it's easier to see why the shortcut might've been taken.
  - alexvoda 4y ago
    Exactly, the logic is that "...", "....", "..*", etc. do not exist and besides users should have the common sense to not name stuff like that. Therefore it is much easier to just use the easier to write (assembler) and much faster solution.
    - wizofaus 4y ago
      "Much" easier? It only needs 3 or 4 extra instructions to check for the null terminator at position 1 or 2 (0 based), which would be an improvement (only 1 or 2 letter filenames starting with dot would be hidden), and a couple of extra to check for dot at position 1. Given all the other things ls has to do, that's negligible.
jxy 4y ago
The second comment there has its merit in UNIX. However, it is moot with namespace in Plan 9. You can have different versions of the same directory structure, per process.
- cryptonector 4y ago
  It's not like it's easy to manage namespaces and what all is in what namespace.
winstonewert 4y ago
> when the file system became hierarchical (it had a very different structure early on). This leaves me to wonder, what was the structure early on?
- aap_ 4y ago
  It was a general graph. Any directory entry could link to any inode. Standardize ., .. and forbid links to directories other than those and from the directory they're in and you get the classic UNIX file tree.
- xdennis 4y ago
  Multics, the predecessor to Unix, was the first OS to use a hierarchical file system. Before that, file systems were typically flat: a single long list of files. I don't know how the original Unix was, but presumably flat.
- cryptonector 4y ago
  IIRC before that Unix had directories, but it wasn't a rooted DAG. I don't recall the specifics, but I suspect you had to know a directory's inode to get to it if you couldn't reach it from where you were.
danieldevries 4y ago
To some degree this is solved when using stow and a dedicated ~/dotfiles directory. No need to dig around in ~/.config But I agree with Pike. ls -a in the home sir, becomes an unorganized mess with all those apps that don't use the xdg default .config folder.
jdlyga 4y ago
I love how so many behaviors we depend on were mistakes or temporary fixes "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move"
- warmwaffles 4y ago
  Nothing more permanent than a temporary solution.
  - donarb 4y ago
    "The fix is temporary, unless it works" -- Red Green
- game-of-throws 4y ago
  The Garden of Eden was transitory.
  - inopinatus 4y ago
    Every omnipotent creator implicitly grasps that initial configuration matters as much as the automaton rules.
    - jakear 4y ago
      Messages from the Unseen World The Universe is the interior of the Light Cone of the Creation Science is a Differential Equation. Religion is a Boundary Condition - Alan Turing
- shrikant 4y ago
  HTTP "Referer" is the one that makes me sad.
  - hsbauauvhabzb 4y ago
    The fact that terminals being an emulation of a teletype comes a close second. And the origins of /usr/bin a definite third.
Night_Thastus 4y ago
That's why some files like gitignore and clang-format start with a dot? Some old way of hiding the file? How bizarre. I had no idea it was actually related to the . and .. files.
- deathanatos 4y ago
  > Some old way of hiding the file? An old way, but also it's still the way to hide a file, on *nix systems. (Hence the "mistake", and the countless hours mentioned in TFA are still adding up, as people forget them when they shouldn't, or don't exclude them when they should…)
  - trebbble 4y ago
    Practically the only remotely common desktop or server OS where it's not still a normal way to hide files, is Windows.
    - naniwaduni 4y ago
      Windows is very common.
      - trebbble 4y ago
        I didn't mean to imply that Windows is uncommon, but that you have to get pretty damn obscure to find another modern desktop or server OS that doesn't do the dot-equals-hidden thing. Windows is the most common on the desktop, obviously, but if you step outside it you're almost certainly in dot-is-hidden territory.
        naniwaduni 4y ago
        Windows is still so overwhelmingly common that it's very possible to never have occasion to touch "another" desktop or server OS. Especially if you don't go out of your way to manage servers, and doubly so if you don't live in one of the rich economies.
esoterae 4y ago
alias ls='ls -a'
- dorfsmay 4y ago
  alias ls='ls -A' There really is no need to show "." And "..". I tend to always start with: ls -lArt
  - esoterae 4y ago
    How interesting (: I find myself typing a lot of `ls -dl /a/b/d/*` these days. What a strange fingerprint I imagine all our collective accumulated behaviors project about our past experiences.
- mark-r 4y ago
  It's not just ls though, the shell hides them too right? echo * won't show them.
  - esoterae 4y ago
    Well, I was being a little flippant dismissing it as largely a complaint about things not showing up in the terminal, but it's obviously deeper than that, yes. I think this overall situation is most acutely a lack of standard. Someone up in the nosebleed section rightly pointed out that there should be some environment variable for a config to be written to, and I agree. I also want to stress that there should be the inclusion of a single variable on top of that, that all programs should use when constructing the path to their configuration. USER_CONFIG_DIR or something equally arguable should, if unset, default to $HOME, and if set, be used as the root to construct whatever structure therein is desired, also able to be changed with an environment variable specific to that program. Be it filename or further subdirectory, first using a single reference that is /not overloaded/, like HOME, but defaults to HOME if unset.
  - wizofaus 4y ago
    Very good point and arguably a bigger problem. Worth putting `shopt -s dotglob` in .bashrc to avoid. How about other shells?
jph 4y ago
One way to make your config files more visible: mv "$HOME/.config" "$HOME/config" ln -sfn "$HOME/config" "$HOME/.config" If you want to move and link files that you want to make visible: mv "$HOME/.foo" "$HOME/config/foo" ln -sfn "$HOME/config/foo" "$HOME/.foo" If you want, you can set a custom location in your system file `/etc/profile` or your user file `~/.profile`, or `~/.bashrc` or `~/.zshenv` etc. export XDG_CONFIG_HOME="$HOME/config" Helpful links for XDG: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... https://wiki.archlinux.org/title/XDG_user_directories https://wiki.archlinux.org/title/XDG_user_directories
- bmurphy1976 4y ago
  Why move the folder? Why not just symlink config to .config? There's almost certainly some poorly written tools out there that will blow up on the symlink. Why take that risk?
  - cafeinux 4y ago
    From a purely esthetic point of view, if you're using a graphical file manager, the symbolic link might be denoted by an ugly icon. Surely there's a solution to that, but that's the only reason I could find.
  - jph 4y ago
    You're correct, moving the folder can expose a poorly written tool, meaning a tool that isn't following the symlink and isn't using XDG_CONFIG_HOME. To me, it's an advantage to surface the latent problems, so I can message the authors to ask them about updating. So far, all authors are good with updating. It turns out the bulk of the issues are in internal scripts that hardcoded ~/.config instead of using XDG_CONFIG_HOME. This is an easy fix, and at the same time we shellcheck those scripts.
- andrewla 4y ago
  I have a directory under ~/config, ~/config/dotfiles, that just has files that are intended to be dot-prefixed and linked in the home directory. That avoids any accidental over-linking; I can just run a script that links ~/config/dotfiles/$X to ~/.$X and I'm done.
BrainVirus 4y ago
Most people seem to interpret this as "don't hide things". I interpret this as "file systems need to have a flexible metadata mechanism instead of ad-hoc hacks". Of course, at this point in time no such thing will happen, because it's easier to invent 100 new databases than change some assumptions about our core architecture.
- jl6 4y ago
  I guess one could mention xattrs but there isn’t a lot of consensus on how they should be used.
  - marcosdumay 4y ago
    Or if they should be used at all. Distros still default into disabling them. What is quite interesting, because it's all a matter of user interface. It's a change that doesn't even impact on software compatibility. Any distro that decides that a file is hidden due to an attr can just push that change, and nothing will break.
- deleted 4y ago
  [deleted]
- klabb3 4y ago
  > I interpret this as "file systems need to have a flexible metadata mechanism instead of ad-hoc hacks". Pike isn't even talking about that, only the typical config files in the home dir that clutter and affect performance of file name ops in the home dir. > (For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names. They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files. Lessons can be learned.) I have to agree. I can't think of any situation where hiding really helps. If the reason is clutter, the solution should be a dir.
  - BrainVirus 4y ago
    >I can't think of any situation where hiding really helps. The irony of dot-files is that they became used for metadata, like .git directories, .htcasses files and so on. So, a solution that fakes metadata by abusing names is now used to indicate metadata at another level of the system. There is clearly something missing in file system design.
andrewla 4y ago
I am increasingly exasperated by apps that do not follow the XDG specification for config at this point. Having a ton of dotfiles sitting in the root of the home directory is just a maintenance nightmare on every level. I've gone so far as to keep my config directory visible -- ~/.config is a symlink to ~/config, which actually holds all my config, conveniently a git repository in itself for easy portability and tracking.
- lillecarl 4y ago
  What a genius idea, I'm gonna write a shell function to "permanently unhide" everything in a directory, I love *nix
  - anamexis 4y ago
    That "function" for me is just `alias ls='ls -a'`
    - lillecarl 4y ago
      Not the same, though there are more tools than ls that use directories.
- qbasic_forever 4y ago
  Stow is a tool designed to support exactly the workflow you describe: https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/
  - spinningarrow 4y ago
    Been using stow for my dotfiles for many years now and I’m really happy with the workflow: https://github.com/spinningarrow/.files https://github.com/spinningarrow/.files
- luma 4y ago
  It really is a mess and it would be helpful if we had some sort of database for configuration that was reasonably standardized. Some sort of "registry" if you will :D
deleted 4y ago
[deleted]
kazinator 4y ago
> I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake. That is highly implausible, except as a case of extremely distracted coding. Someone like Thompson or Ritchie wouldn't consciously write a test for just the leading dot without being fully aware that it matches more than . and .. . Even if the thought had been "nobody in their right mind will have files starting with dot, so who cares", that would still make it a deliberate requirement being consciously implemented and not a mistake. By distracted coding I mean that situations like this happen: you intend to write a piece of code which does something specific. The code is motivated by certain happy cases. You start coding it and get it into a state in which it runs but doesn't quite do what was intended. Then you get completely distracted by some interruption. You forget that the code hadn't been completed; you mistake the remembered intent for the completion. You run the code and it carries out the intent on the motivating happy cases, and somehow fool yourself into believing it was done. Maybe Pike meant that it was a mistake to create that requirement. I don't hate the $HOME/cfg directory idea, but please call it $HOME/.cfg so I don't have to see it. :)
- pxc 4y ago
  > Someone like Thompson or Ritchie wouldn't consciously write a test for just the leading dot without being fully aware that it matches more than . and .. . Why not? Alternatively, who said the decision was 'conscious'? It doesn't take a dumb person to make a dumb mistake. Brilliant people get things wrong all the time, and anyone can be hasty or careless in a moment.
  - kazinator 4y ago
    I believe I cover all your remarks with the discussion about distracted coding. If it was a coding mistake, it would have to have been something like that. It's not a coding mistake where some wrong identifier was used or other typo; coding the proper test requires more instructions. You have to check that there is either a 0 byte after the first '.', or else another '.' byte that is followed by a 0. Here is how someone could be distracted halfway through and forget to finish it. Suppose the code has a structure like this: for (;;) { if (getnext(name) < 0) break; /* code added to skip . and .. */ if (name[0] != '.') /* if it doesn't start with a dot, print it */ goto print; /* This can be continued here with more logic without changing the above line; But it would already skip . and .. with just the above line. */ if (name[1]) { /* two or more chars */ if (name[1] != '.') /* Dot followed by non-dot: print it */ goto print; if (name[2] != 0) /* Two dots, followed by non-dot: print it */ goto print; /* confirmed dot-dot */ } /* confirmed dot or dot-dot */ continue; print: puts(name); } And the code does have this structure: it tests for the . character, and branches forward if not equal. Whenever that bne branch is taken, the situation is correct. cmpb (r3),$'. bne 2f sub $8.,r1 br 1b 2: jsr r5,gstat br 1b So this could be corrected with further refinements by adding more instructions after the bne where the branch is not taken, without changing the prior instructions. If the behavior was indeed not intended, this would be a case of incomplete code. Incomplete code can happen by distraction. You turn your attention to something else, perhaps for the span of several days, and then don't remember the incomplete state. The brain had visualized the complete state, leaving a false memory of that having been done. On a related note, one element that is gapingly absent from all historic Unix sources is ... test cases! Compiler test cases, shell test cases, utility test cases, library function (and system call) test cases ... They are nowhere to be seen.
vrnvu 4y ago
I got me a copy of The Unix Programming Environment (1984) by Pike and Kernighan last year. It has plenty of hidden small design gems or anecdotes like this one. For example, why files don't need a \EOF char, it's implicit when you don't read more bytes the you have reached the end of a file... Unix design was about making things work (1) and simple (2).
- chasil 4y ago
  This book is online for free (three cheers for exotic spelling at archive.org). http://files.catwell.info/misc/mirror/the-unix-programming-environment-kernighan-pike.pdf http://files.catwell.info/misc/mirror/the-unix-programming-e... https://archive.org/details/UnixProgrammingEnviornment https://archive.org/details/UnixProgrammingEnviornment
- cma 4y ago
  I wonder if \EOF was around due to punch cards? You maybe didn't want an implicit EOF in case you lost the last card.
  - int_19h 4y ago
    EOF was around because many early file systems only recorded the number of allocated blocks per file, so some other mechanism was needed to record the precise length in bytes in cases where padding with spaces was not acceptable.
    - bombcar 4y ago
      Exactly - think about a tape with multiple files on it - you want some way of knowing you reached the end of a file without having to seek all the way back to some directory.
csydas 4y ago
Maybe a dumb question but why do so many apps rely on dotfiles when /etc exists? I'm not making a judgement, this is an earnest question as even though it's meant for system config files, is there any reason that all app configurations shouldn't live there? If not in /etc, then at least /usr/etc? I'm sure there is some historical reason but some brief searching and I've not really come up with why dotfiles everywhere are preferable to a centralized configuration directory.
- dooglius 4y ago
  Multi-user systems, where things outside $HOME are not editable, and where different users may have different configurations.
- ews 4y ago
  I assume that because on true multi-user systems, syncing permissions between $HOME and /usr/etc/$USER may be a complete disaster.
  - nmz 4y ago
    Back ups would require you to know which paths are actually yours and where, chrooting would be problematic.
- CleverLikeAnOx 4y ago
  Dotfiles are a per user application config. Other users of the same system are unlikely to want my idiosyncratic zsh setup. Hence the suggestion for $HOME/cfg in the article.
- PeterWhittaker 4y ago
  Apps can rely on both /etc (for system defaults) and on ~/.something (for per user defaults). If we used only /etc, then we would need per user entries there, which would be far more difficult, esp. with network-mounted home folders, especially when those are automounted.
  - 4y ago
quickthrower2 4y ago
I recently learned about this "mistake". I always assumed the dotfile was some design feature by ancient "gurus" of UNIX rather than an accident. There is something nice and immediate about adding a dot to make it invisible to certain things (ls by default, the file explorers in ubuntu by default, etc.) A bit like file extensions themselves and the weight they carry in Windows. It sorts of balances in favour of immediacy of the function over "right way to do things", where the right way might be some kind of meta data for the file, or for it's folder. Funny thing about hiding, is what does it mean to hide? If you can ask your utility to show hidden things. It sort of means "things I reckon people don't wanna see, or shouldn't touch, unless they are willing to take a step to see it". A bit like a shibboleth where if you can't figure out how to see it, you are too dangerous/dumb to edit it, or even know about it. You could instead have security settings for that. Maybe you just don't give the user access to the files at all until they elevate from user to "poweruser". Which would be somewhere between user and superuser. Use chmod to set the permissions, instead of a dot filename format.
- IncRnd 4y ago
  > I recently learned about this "mistake". I always assumed the dotfile was some design feature by ancient "gurus" of UNIX rather than an accident. He said the decision was certainly a mistake, which is an error in judgement, and pretty sure it was an accident, which is an unexpected incident. It is a mistake to conflate the two.
  - quickthrower2 4y ago
    I am not sure whether this was a mistake or accident based on those definitions, it is a close call. But thinking in those terms is certainly good for clarity of thought, so thanks!
- pxc 4y ago
  > Funny thing about hiding, is what does it mean to hide? If you can ask your utility to show hidden things. It sort of means "things I reckon people don't wanna see, or shouldn't touch, unless they are willing to take a step to see it". One thing I like about hidden files via the dot prefix is that I feel like it makes clear that the files are hidden only by convention. It's not a security feature, it's just a convenience to help spare you the mental overhead of witnessing the clutter.
croes 4y ago
>I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake. So it's just an assumption and so the title is misleading
unixbane 4y ago
this post is a good example of how un*x hippies with their fried brains from too much drugs* realize one unit of common sense after aeons of contemplation. just like with generics in go. in fact, go itself is just decades of C users very slowly conceding to the idea of basic hygiene. it took them decades to come up with something which is essentially just what was already available in the 90s (pascal, fortran, ada, basic, later java 1.2 or so which also had green threads), but with stuff done a certain way so the boomers can be like "oh see, we did this minor syntactic change THIS way, checkmate, pascal"), in other words they want to have their say in everything * im not joking, this is what un*x culture appears to essentially boil down to. boomers were all hippies in the 70s despite presenting themselves as "austere" and "mature" "wise" individuals now, which had the unfortunate side effect of too much drugs. further research is needed to clarify whether brain damage is caused by drugs or un*x any encoding in file names at all is a mistake. this includes character encodings too, which may sound like a non-sequitur but its not. in fact, files should only have unique identities, not names. names should be metadata. folder hierarchy should just be a user defined data structure that can reference these said "files". anyone who tries developing their own OS without copying extremely idiosyncratic un*x ideas and without being bogged down by the overhead of assembly language or C quickly learns this. an example of youngins discovering this is IPFS (and subsequently implementing it on top of broken un*x)
- arboles 4y ago
  lmao based
- qbasic_forever 4y ago
  This is an AI generated comment, right? You didn't get a job at freaking AT&T Bell Labs by being a pot smoking hippie. They were the squarest of square professionals--suit, tie, the whole bit.
  - unixbane 4y ago
    no, it just doesn't fit into your two categories of posters here on HN
kazinator 4y ago
This is reminiscent of John MacCarthy pooping on NIL. "The unexpected appearance of an interpreter tended to freeze the form of the language, and some of the decisions made rather lightheartedly for the ``Recursive functions ...'' paper later proved unfortunate. These included the COND notation for conditional expressions which leads to an unnecessary depth of parentheses, and the use of the number zero to denote the empty list NIL and the truth value false. Besides encouraging pornographic programming, giving a special interpretation to the address 0 has caused difficulties in all subsequent implementations. " (History of Lisp, 1979)
- gryn 4y ago
  the explanation for pornographic programming are very interesting: https://stackoverflow.com/questions/8547142/what-did-john-mccarthy-mean-by-pornographic-programming https://stackoverflow.com/questions/8547142/what-did-john-mc... > 0==() has been the emoticon for pornography since 1958. > The fact that too many implementation details were leaking at a higher level, i.e. showing up too much > Code that uses intimate knowledge.
transfire 4y ago
100% I’m on the verge of abandoning the home directory. I’ll put My files elsewhere and leave home to the apps. I thought XDG would surely solve this problem but it’s painfully clear now that most developers just don’t care. `node_modules` and `snap` are good cases in point. They didn’t even bother hiding them! LOL
smm11 4y ago
However Apple does it is best.
PeterWhittaker 4y ago
Pike may be right that it was a coding error (but cf comments elsewhere re the unlikelihood that Ritchie, e.g., wouldn’t have thought of those other cases), but I think he’s wrong about it being a mistake. I love dotfiles. When I list a folder, I don’t want to see all the cruft, I want to see the key stuff. Sometimes when I organizing something new, I use .directoryName to hide things temporarily. git is one of my favourite examples: .git hides stuff I do NOT need to see every day, leaving behind the things I am actually working on, the things I care about. Besides, it is so easy, once one has CLIed a while, to find (no pun intended) and/or account for dot files when you need to.
- llanowarelves 4y ago
  If that wasn't already the behavior, people might do things like prefix with "_" or "__" to sort all the cruft to the top. "__git".
- ablob 4y ago
  I still think it is a mistake which you may be repeating by conflating two concepts: - The location of a file - Standard visibility of the file If you hide something (like a folder) temporarily and refer to it through a script, you have to go to the script and change it once you decide that you don't want the folder hidden anymore. The script is now coupled to not only the location of the resource, but also its visibility. There is no reason to conflate the two concepts. Git folders can still be hidden by default without requiring adaptation to path names. I'd argue, what you're loving about dotfiles is not the presence of the dot, but the concept of visibility levels on files.
  - account42 4y ago
    But combining these concepts is useful - with a .dot you know based on the name alone if it is hidden or not. If there was a hidden flag then whether or not a file is hidden is itself hidden. E.g. you could have something referring to a file by any name which your file browser / ls does not show and but the file is still there and will be loaded - that's unnecessarily surprising.
noncoml 4y ago
First of all, “A lot of other lazy programmers”. That’s cringe. I don’t care who you are, that’s not a way to talk. Secondly, I think we have all been there. We introduce a bug in an interface/API but then the users of it start depending on this behaviour and before you know it it’s a feature and it’s impossible to fix without breaking the world.
- cmrdporcupine 4y ago
  He's obviously a very smart guy and a pioneer and a much more accomplished person than me (or most of us), but Rob Pike seems to make a habit of arrogantly talking down about other people's intelligence or skill: Re: Go “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” -- Rob Pike I agree it's really a cringe way of approaching people. In this (dotfile) case there may have been some self-deprecation in the comment though, so it's frankly hard to get too miffed about it.
  - shepherdjerred 4y ago
    I think he very accurately described the problem Go is trying to solve which is how do you make new grads productive? In my experience at AWS people that graduated didn't understand the languages we used. This leads to a bunch of problems, and makes it's easy to write very bad, unmaintainable code. Lots of needless class hierarchies in Java, or a misunderstanding of `this` in JavaScript. Go solves the problem perfectly.
    - cmrdporcupine 4y ago
      Never had that experience at Google. New grads and interns always seemed sharp. Might just be the superior quality of education out of U of Waterloo, or the hiring bar at our site, or both. I enjoyed working with them. With new grads, I generally didn't have to teach coding knowledge. It was more about transmitting wisdom around best practices, estimation, architecture, etc. If anything, to me Go makes a lot of things harder that could be simpler. Lack of generics means boilerplate. Eschewing test frameworks means boilerplate. The structural typing stuff is exotic (but neat I guess) and not familiar to most new programmers. The actor / CSP type concurrency stuff is also exotic and not familiar to most new programmers. I don't see how it's a language for new programmers. It also seems very much like a rehash of the concepts they had in Limbo so I actually don't find it honest for him to be claiming it was designed for this purpose (to simplify programming). Instead it feels very much like they had a hammer in search of a nail, an itch they've been scratching since the Plan9 days. And that's fine. I just don't buy this pitch about its market niche and the stuff about the relative intelligence of programmers is gratuitous. I've seen some very smart new grads produce amazing Rust code for example.
mikl 4y ago
I agree that it’s annoying that so much junk accumulates in the root of your home dir. But any consumer-facing OS will need some sort of mechanism of hiding/protecting configuration files/logs/etc. from deletion by clueless users, like how macOS has started hiding ~/Library by default.
- int_19h 4y ago
  The article points out that a better way to do this would be to designate one particular folder for configs, and then that alone could be hidden if desired. But we have what we have instead because a "convenient" hack was misappropriated.
  - mikl 4y ago
    Yes, but it also claims that hidden files in general were a mistake and mentions how Plan9 not having hidden files was learning from this mistake.
    - bombcar 4y ago
      Config files are only one subset of possible dotfiles (a common one to be fair).
hk1337 4y ago
A happy little accident
coldtea 4y ago
>How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago? Not many? In the sense that, considering several UNIX and C design issues and footguns, the dotfiles are the least of our worries (compare e.g. to C buffer overflows or shell escaping rules, to name but two)... I also don't particularly like the repeated ditches at "lazy programmers" - isn't the whole "New Jersey" style [1] heavy on laziness? In fact, if those "lazy programmers" were given OS level-APIs and libs doing the right thing about dotfiles, they wouldn't have recoded them on their own in their programs... [1] https://en.wikipedia.org/wiki/Worse_is_better#New_Jersey_style https://en.wikipedia.org/wiki/Worse_is_better#New_Jersey_sty...
- doctor_eval 4y ago
  That link is awesome. Thanks.
- pantulis 4y ago
  It's not my intention to second guess Ken, but at least in terms of performance I'd say that the current user home directory structure would bet a hit in the buffer cache since Unix got filesystem buffer caches. In terms of wasted CPU cycles, it's another story but hey these are the days of using npm packages to basically do a string comparison.
- ParetoOptimal 4y ago
  Not a fan of worse is better. I have some rough thoughts on expressing why: > This leads one of the major cognitive biases in software development where people speak of tradeoffs without establishing they are Pareto Optimal, and wrongly arriving at the conclusion “nothing more can be done without a huge effort”. https://www.paretooptimal.dev/pareto-optimality-and-software-development/ https://www.paretooptimal.dev/pareto-optimality-and-software...
  - coldtea 4y ago
    >Not a fan of worse is better. That's ironic given your handle on HN :) >This leads one of the major cognitive biases in software development where people speak of tradeoffs without establishing they are Pareto Optimal, and wrongly arriving at the conclusion “nothing more can be done without a huge effort”. Well, part of the idea is to do the "pareto optimal" work not just implementation-wise, but also in checking whether the tradeoffs are pareto optimal (pareto-ception). Thus, avoid "analysis paralysis"
codedokode 4y ago
Adding . and .. was a mistake by itself. I never needed them, but always had to write conditions to skip them when traversing the file system. Also, dotfiles don't work well with masks because `*` doesn't match dot-files, and `.*` match all dotfiles including . and .. which causes many programs to fall into endless recursion (for example, `du -sh .*`). Everything related to dotfiles in Linux is done wrong.
- GekkePrutser 4y ago
  Wildcards are entirely shell-dependent so blame the shell you're using, not Linux :)
  - debugnik 4y ago
    glob and fnmatch are C functions defined in POSIX though.
im3w1l 4y ago
A long time ago I liked listening to original soundtracks for games. Winamp had a plugin that would play .psf (et al) files. There were files that contained the extracted code from games for playing the music. The plugin had a tiny builtin emulator that could run the relevant parts. No graphics or input I suppose. One soundtrack I really liked was .hack, including the leading dot. Given that "hack" part and the overall theme of the games I assume the initial dot was quite intended. But what the creators could not have foreseen was that their soundtrack was missing from the majority of psf mirrors (but some had it obviously). I guess some part of some stack ignored dot-prefixed files when doing the mirroring. Anyway, although I'm usually opposed to inband signalling, I am a fan of dot-prefix for hiding. Filenames already have so many special corner cases that you would have to treat them very carefully even without this one. The fact that it is embedded in the name means that any system can roundtrip hiddenness - something that cannot be said for metadata.
swellguy 4y ago
He's probably just ignorant of how bad things can get. Hidden files in a home directory is a lot better than what other operating systems came up with (random directories and the dreaded registry). I'd call it a win - the search over a home directory inode is not going to bother anyone either way.
heikkilevanto 4y ago
Dotfiles are useful, not only in the $HOME directory, but in every project that has a .git directory, and many other ways. Maybe it was a design accident, but it has got stuck, and many old greybeards like me are used to it, and find good use of it.
lofatdairy 4y ago
>I was wondering why this post had so many comments. Then I found out it was posted on proggit/HN. The discussions there were hardly interesting, however. For the curious (was a bit annoying to find since gplus is down now and all links redirect to a different subdomain): https://news.ycombinator.com/item?id=4331855 https://news.ycombinator.com/item?id=4331855
alpaca128 4y ago
> my home directory has about a hundred dot files [...]. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge. Nothing against software efficiency, but those hundred loop iterations checking a string aren't going to be the big time-waster of your daily life.
labrador 4y ago
I feel consternation about symlinks on Windows. I find them extremely useful, but you never know which program is going to ignore them and which program is going to follow them. They're inconsistent. Plus you can't tell by looking at files if they are symlinks or not because they have the same icon as shortcuts. I recently managed to crash Visual Studio 2022 because I had a symlink to a drive with a hidden $RECYCLE_BIN on it. If you copy files in Windows the system will copy the contents of symlinks, however many backup programs will not follow symlinks.
ggm 4y ago
I find the best way to read a Pike statement is to take it as a challenge to your own strongly held belief. I like .dotfiles behaviour and ls -a does not distress me. But, he makes a case it was not deliberate and probably less beneficial than we think. So I look at that as a reframing: do I have a good rebuttal? No. I have my own muscle memory and comfort factor, but that's all. How would I think if dotfile hiding didn't happen? Hiding . & .. is arguably as silly. It's not like they can ever not exist but why hide them?
cvccvroomvroom 4y ago
Dotfile synchronization is a necessary evil. At work, we have a dotfile synchronization system that contains an infrastructure-level yml file of what to save, what are history files, and what to exclude. Every time a modification is made, it saves a revision. You can have multiple dotfile environments also that completely swaps them out. On the work laptop, I have google drive saving a .dotfiles dir with symlinks into them.
p4bl0 4y ago
All my important dotfiles are symlinks to ~/local/etc, which is versioned. $ ls -R1 local/etc local/etc: bash_aliases bashrc gitconfig inputrc nanorc ocamlinit ssh unison XCompose local/etc/ssh: config local/etc/unison: backup.prf
andix 4y ago
Dot files are much better than hidden files on Windows (and before DOS). There you need additional attributes to hide files. And hidden files seem to be an important thing. Some things you need to hide from the end user.
- saba2008 4y ago
  >Some things you need to hide from the end user. De-emphasize - maybe, hide - no. Garbage pile that is average Linux home directory is pretty much result of 'out of sight - out of mind' practice, enabled by dotfiles being hidden. I wish Linux settled on single `~/System/` directory, mirroring `/` structure. On the other hand, dotfiles convention is useful for meta/"parallel" data, `.git` being prime example - something tighly linked with abitrary file structure.
  - andix 4y ago
    Sure, the dot files in ~/ are a mess. It would be so much cleaner if the convention would've bin similar to /var, /etc, and so on. ~/.var/cache or ~/.etc/

324 points by varbhat 4y ago

just put them all in ~/configs ... many apps still pollute ~/

Haha, the first comment is of me throwing shade on HN, oh geez. Now I'm curious to read the old HN thread that I thought was so disappointing: https://news.ycombinator.com/item?id=4331855 https://news.ycombinator.com/item?id=4331855

deleted 4y ago
[deleted]

throw7 4y ago

Don't worry Rob. Freedesktop.org learned and spammed my home dir with Desktop/Document/Downloads/Music/etc/etc/etc...

kodah 4y ago
What Rob is griping about is more analogous to $HOME/.config now, or /var/run for non-user specific stuff.
- t-3 4y ago
  It's even worse with dotfiles nowadays than before. We have the cluttered "xdg" dotfile directories, and then a bunch of stuff makes random dotfiles/dotdirs in the home directory, and then .profiles/shellrcs/xinits that are basically required. Every single program seems to think you want a scrollback history, a configuration directory, or some random garbage to remind of you of that one time used it.
  - samatman 4y ago
    Complying with the XDG standard seems about as good as a stringly typed OS like Unix can get. Part of which is making sure that the defaults the program chooses may be overridden by consistent environment variables. Programs need some way to persist their own state and configuration, after all. The fact that XDG is more honored in the breach is tiresome, but this can at least be corrected, and it's well enough put together to be a steady-state approach to wrangling dotfiles.
  - deleted 4y ago
    [deleted]
  - nmz 4y ago
    Windows fixed this by just having %APPDATA%, and to me, its a great idea. No .config, no .local, no .share, no .randomfile, each installed program has its directory in hidden directory, and nobody has to know what each directory is for, and sure, this is what ~/.config is for some, but I also see there's some stuff in ~/.local/share and so on. To expand on this, when a program gets installed, it should write its binary location in a file, then if you ever erase it, a doesthisexistanymore $Config/dir/*/symlink | remove_entire_configuration_directory should be run via cron daily. No manual cleanup, ever.
    - kodah 4y ago
      Slight correction here, XDG keys are analogous to Windows standards: https://github.com/adrg/xdg/blob/master/README.md https://github.com/adrg/xdg/blob/master/README.md
psanford 4y ago
That is annoying but easily fixed with xdg-user-dirs-update eg: xdg-user-dirs-update --set MUSIC ~/.xdg-user-dir/music
- jrockway 4y ago
  I had no idea. Excellent tip!
- UI_at_80x24 4y ago
  My annoyance is that they create any 'helpful' directories. It's just as bad on Windows. "Download", "Pictures", "3D crap", etc.... Nope, fuck that. This is my $home, I'll make it look how I want.
  - alexvoda 4y ago
    You may indeed prefer an empty canvas you have full control over. However, creating these folders by default is actually beneficial to most users. Most users (especially the vast majority that transitioned from Windows) expect these folders to exist. I believe the choice to not create these existed and still exists. Yet either all the distros that made that choice are history or they all made the opposite choice. I can say the same about other choices. I vastly prefer having a TRRS headphone jack and expandable storage on a phone. These do not appear to be priorities for most people.
    - adrusi 4y ago
      The choice not to create these directories basically doesn't exist, because all sorts of software will automatically create them if they don't exist, their creation isn't centrally orchestrated. A while back I was using a minimal i3-based desktop and when I launched transmission-gtk it thought I might want a "Downloads" folder, and would create it whenever it launched, even though it had been configures to download files elsewhere.
      - alexvoda 4y ago
MichaelCollins 4y ago
I've never seen anybody use these trashy preset directories as intended. Experienced users ignore them or delete them, using their own directory structure instead. Inexperienced users use one of them (usually Downloads or Desktop) while the others are treated as write-sometimes/read-never; e.g. sometimes they accidentally have files saved to those other directories which may as well be that file disappearing into the void never to be seen again. These presets only serve to confuse or at best annoy. These directories were well-intentioned originally but proved to be a huge mistake. They need to go away. (Edit: The above rant applies only to Downloads/Music/Video/etc. I think ~/.config and ~/.local are fine. I have no problem using those as intended, and I've seen plenty of other people using them too.)
- pdntspa 4y ago
  Windows users use them, Mac users use them, hell even on a fresh profile in Gnome I use them... It is a little weird to see htem on a server OS install though
  - rgovostes 4y ago
    They exist on macOS and Windows but I tend to agree that these directories are not particularly useful for users. Apple software tries to organize files but it's a disaster: iTunes used to download movies to ~/Music/iTunes/iTunes Media/Movies, now TV.app downloads them to ~/Movies/TV/Media/Movies (!), and videos I shoot on my iPhone end up in ~/Pictures.
    - pdntspa 4y ago
      There has always been a tragedy of the commons with these folders, nobody can agree on where a lot of stuff goes. Should my game saves go in Documents? What about Documents/My Games/Publisher? What about %APPDATA%/Publisher? Hell there's even a few in ~/My Games. Every new game, figuring out where the save data went is an adventure and it's cluttered up every folder it touches. And now for whatever reason everyone is being pushed to put user data in %APPDATA%, which I don't consistently remember how to get to without that shortcut. So who knows! I just looked up the save data location for Subnautica and it is (I shit you not): %AppData%\..\LocalLow\Unknown Worlds\Subnautica\Subnautica\SavedGames
petepete 4y ago
I like to lowercase mine so bin and projects don't look weirdly out of place. Thankfully it's totally customisable. https://github.com/peteryates/dotfiles/blob/master/xdg/.config/user-dirs.dirs https://github.com/peteryates/dotfiles/blob/master/xdg/.conf...
jmclnx 4y ago
I agree, but the OpenBSD did some nice things in regards to ~/Downloads Using unveil() and pledge(), OpenBSD hides many $HOME and system directories from Firefox and chrome. Thus an errant javascript will only see things in ~/Downloads So one nice use for these.
deleted 4y ago
[deleted]

LukeShu 4y ago

The code in question: https://github.com/dspinellis/unix-history-repo/commit/389a475ba0445aa2816f84796786568a762a930d#diff-02d9990bf5c5bbe1b4473ff16783b30ec389fff3ffe30189990a48b6cbf72239R120 https://github.com/dspinellis/unix-history-repo/commit/389a4...

pengaru 4y ago
Funny. People here are conjecturing why one open codes the comparison instead of calling strcmp() presuming it's C when `ls` was written in assembler where calling a C function like strcmp() is far more onerous (and slow) vs. comparing to an immediate (cmpb, bne).
- ghayes 4y ago
  To be fair, it doesn’t need to be strcmp since the target is known. It could simply check for a null terminator on the next byte or another dot followed by a null terminator. Surely a few more instructions, but not a complex subroutine call.
- draw_down 4y ago
  I don’t code in C too much but it seems like it would be pretty simple to check if the next index is a null byte.
dsQTbR7Y5mRHnZv 4y ago
And the modern reimplementation: https://github.com/coreutils/coreutils/blob/c7920f2/src/ls.c#L3138 https://github.com/coreutils/coreutils/blob/c7920f2/src/ls.c...
- Gibbon1 4y ago
  All I have to say looking at that is Absolutely Disgusting.
  - wruza 4y ago
    Not sure why your comment is grey, because ! name[1 + (name[1] == '.')] is an absolutely unnecessary code golf bullshit sitting right there.

hbn 4y ago

That's an interesting history lesson! I always assumed hidden dotfiles was a conscious design decision.

clysm 4y ago
It's not a history lesson. It's just baseless conjecture.

kgeist 4y ago

I don't understand how skipping an entry by comparing it with strcmp(name, ".") == 0 turned into name[0] == '.' Is it what really happened (lots of programmers, by mistake, wrote a comparison function which is just plain wrong), or Rob Pike is conjecturing?

deleted 4y ago
[deleted]
laurent123456 4y ago
He seems to be saying it was a shortcut, so that the line excludes both "." and ".."
Retr0id 4y ago
They weren't replacing `strcmp(name, ".")`, they were replacing `strcmp(name, ".") == 0 || strcmp(name, "..") == 0`. It's somewhat easy to see how someone would make this shortcut when programming in C, but they weren't programming in C, they were programming in assembly (as the article describes). It's so much simpler to only check the first char when programming in assembly, so it's easier to see why the shortcut might've been taken.
- alexvoda 4y ago
  Exactly, the logic is that "...", "....", "..*", etc. do not exist and besides users should have the common sense to not name stuff like that. Therefore it is much easier to just use the easier to write (assembler) and much faster solution.
  - wizofaus 4y ago
    "Much" easier? It only needs 3 or 4 extra instructions to check for the null terminator at position 1 or 2 (0 based), which would be an improvement (only 1 or 2 letter filenames starting with dot would be hidden), and a couple of extra to check for dot at position 1. Given all the other things ls has to do, that's negligible.

jxy 4y ago

The second comment there has its merit in UNIX. However, it is moot with namespace in Plan 9. You can have different versions of the same directory structure, per process.

cryptonector 4y ago
It's not like it's easy to manage namespaces and what all is in what namespace.

winstonewert 4y ago

> when the file system became hierarchical (it had a very different structure early on). This leaves me to wonder, what was the structure early on?

aap_ 4y ago
It was a general graph. Any directory entry could link to any inode. Standardize ., .. and forbid links to directories other than those and from the directory they're in and you get the classic UNIX file tree.
xdennis 4y ago
Multics, the predecessor to Unix, was the first OS to use a hierarchical file system. Before that, file systems were typically flat: a single long list of files. I don't know how the original Unix was, but presumably flat.
cryptonector 4y ago
IIRC before that Unix had directories, but it wasn't a rooted DAG. I don't recall the specifics, but I suspect you had to know a directory's inode to get to it if you couldn't reach it from where you were.

danieldevries 4y ago

To some degree this is solved when using stow and a dedicated ~/dotfiles directory. No need to dig around in ~/.config But I agree with Pike. ls -a in the home sir, becomes an unorganized mess with all those apps that don't use the xdg default .config folder.

jdlyga 4y ago

I love how so many behaviors we depend on were mistakes or temporary fixes "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move"

warmwaffles 4y ago
Nothing more permanent than a temporary solution.
- donarb 4y ago
  "The fix is temporary, unless it works" -- Red Green
game-of-throws 4y ago
The Garden of Eden was transitory.
- inopinatus 4y ago
  Every omnipotent creator implicitly grasps that initial configuration matters as much as the automaton rules.
  - jakear 4y ago
    Messages from the Unseen World The Universe is the interior of the Light Cone of the Creation Science is a Differential Equation. Religion is a Boundary Condition - Alan Turing
shrikant 4y ago
HTTP "Referer" is the one that makes me sad.
- hsbauauvhabzb 4y ago
  The fact that terminals being an emulation of a teletype comes a close second. And the origins of /usr/bin a definite third.

Night_Thastus 4y ago

That's why some files like gitignore and clang-format start with a dot? Some old way of hiding the file? How bizarre. I had no idea it was actually related to the . and .. files.

deathanatos 4y ago
> Some old way of hiding the file? An old way, but also it's still the way to hide a file, on *nix systems. (Hence the "mistake", and the countless hours mentioned in TFA are still adding up, as people forget them when they shouldn't, or don't exclude them when they should…)
- trebbble 4y ago
  Practically the only remotely common desktop or server OS where it's not still a normal way to hide files, is Windows.
  - naniwaduni 4y ago
    Windows is very common.
    - trebbble 4y ago
      I didn't mean to imply that Windows is uncommon, but that you have to get pretty damn obscure to find another modern desktop or server OS that doesn't do the dot-equals-hidden thing. Windows is the most common on the desktop, obviously, but if you step outside it you're almost certainly in dot-is-hidden territory.
      - naniwaduni 4y ago
        Windows is still so overwhelmingly common that it's very possible to never have occasion to touch "another" desktop or server OS. Especially if you don't go out of your way to manage servers, and doubly so if you don't live in one of the rich economies.

esoterae 4y ago

alias ls='ls -a'

dorfsmay 4y ago
alias ls='ls -A' There really is no need to show "." And "..". I tend to always start with: ls -lArt
- esoterae 4y ago
  How interesting (: I find myself typing a lot of `ls -dl /a/b/d/*` these days. What a strange fingerprint I imagine all our collective accumulated behaviors project about our past experiences.
mark-r 4y ago
It's not just ls though, the shell hides them too right? echo * won't show them.
- esoterae 4y ago
  Well, I was being a little flippant dismissing it as largely a complaint about things not showing up in the terminal, but it's obviously deeper than that, yes. I think this overall situation is most acutely a lack of standard. Someone up in the nosebleed section rightly pointed out that there should be some environment variable for a config to be written to, and I agree. I also want to stress that there should be the inclusion of a single variable on top of that, that all programs should use when constructing the path to their configuration. USER_CONFIG_DIR or something equally arguable should, if unset, default to $HOME, and if set, be used as the root to construct whatever structure therein is desired, also able to be changed with an environment variable specific to that program. Be it filename or further subdirectory, first using a single reference that is /not overloaded/, like HOME, but defaults to HOME if unset.
- wizofaus 4y ago
  Very good point and arguably a bigger problem. Worth putting `shopt -s dotglob` in .bashrc to avoid. How about other shells?

jph 4y ago

One way to make your config files more visible: mv "$HOME/.config" "$HOME/config" ln -sfn "$HOME/config" "$HOME/.config" If you want to move and link files that you want to make visible: mv "$HOME/.foo" "$HOME/config/foo" ln -sfn "$HOME/config/foo" "$HOME/.foo" If you want, you can set a custom location in your system file `/etc/profile` or your user file `~/.profile`, or `~/.bashrc` or `~/.zshenv` etc. export XDG_CONFIG_HOME="$HOME/config" Helpful links for XDG: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... https://wiki.archlinux.org/title/XDG_user_directories https://wiki.archlinux.org/title/XDG_user_directories

bmurphy1976 4y ago
Why move the folder? Why not just symlink config to .config? There's almost certainly some poorly written tools out there that will blow up on the symlink. Why take that risk?
- cafeinux 4y ago
  From a purely esthetic point of view, if you're using a graphical file manager, the symbolic link might be denoted by an ugly icon. Surely there's a solution to that, but that's the only reason I could find.
- jph 4y ago
  You're correct, moving the folder can expose a poorly written tool, meaning a tool that isn't following the symlink and isn't using XDG_CONFIG_HOME. To me, it's an advantage to surface the latent problems, so I can message the authors to ask them about updating. So far, all authors are good with updating. It turns out the bulk of the issues are in internal scripts that hardcoded ~/.config instead of using XDG_CONFIG_HOME. This is an easy fix, and at the same time we shellcheck those scripts.
andrewla 4y ago
I have a directory under ~/config, ~/config/dotfiles, that just has files that are intended to be dot-prefixed and linked in the home directory. That avoids any accidental over-linking; I can just run a script that links ~/config/dotfiles/$X to ~/.$X and I'm done.

BrainVirus 4y ago

Most people seem to interpret this as "don't hide things". I interpret this as "file systems need to have a flexible metadata mechanism instead of ad-hoc hacks". Of course, at this point in time no such thing will happen, because it's easier to invent 100 new databases than change some assumptions about our core architecture.

jl6 4y ago
I guess one could mention xattrs but there isn’t a lot of consensus on how they should be used.
- marcosdumay 4y ago
  Or if they should be used at all. Distros still default into disabling them. What is quite interesting, because it's all a matter of user interface. It's a change that doesn't even impact on software compatibility. Any distro that decides that a file is hidden due to an attr can just push that change, and nothing will break.
deleted 4y ago
[deleted]
klabb3 4y ago
> I interpret this as "file systems need to have a flexible metadata mechanism instead of ad-hoc hacks". Pike isn't even talking about that, only the typical config files in the home dir that clutter and affect performance of file name ops in the home dir. > (For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names. They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files. Lessons can be learned.) I have to agree. I can't think of any situation where hiding really helps. If the reason is clutter, the solution should be a dir.
- BrainVirus 4y ago
  >I can't think of any situation where hiding really helps. The irony of dot-files is that they became used for metadata, like .git directories, .htcasses files and so on. So, a solution that fakes metadata by abusing names is now used to indicate metadata at another level of the system. There is clearly something missing in file system design.

andrewla 4y ago

I am increasingly exasperated by apps that do not follow the XDG specification for config at this point. Having a ton of dotfiles sitting in the root of the home directory is just a maintenance nightmare on every level. I've gone so far as to keep my config directory visible -- ~/.config is a symlink to ~/config, which actually holds all my config, conveniently a git repository in itself for easy portability and tracking.

lillecarl 4y ago
What a genius idea, I'm gonna write a shell function to "permanently unhide" everything in a directory, I love *nix
- anamexis 4y ago
  That "function" for me is just `alias ls='ls -a'`
  - lillecarl 4y ago
    Not the same, though there are more tools than ls that use directories.
qbasic_forever 4y ago
Stow is a tool designed to support exactly the workflow you describe: https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/
- spinningarrow 4y ago
  Been using stow for my dotfiles for many years now and I’m really happy with the workflow: https://github.com/spinningarrow/.files https://github.com/spinningarrow/.files
luma 4y ago
It really is a mess and it would be helpful if we had some sort of database for configuration that was reasonably standardized. Some sort of "registry" if you will :D

deleted 4y ago

[deleted]

kazinator 4y ago

> I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake. That is highly implausible, except as a case of extremely distracted coding. Someone like Thompson or Ritchie wouldn't consciously write a test for just the leading dot without being fully aware that it matches more than . and .. . Even if the thought had been "nobody in their right mind will have files starting with dot, so who cares", that would still make it a deliberate requirement being consciously implemented and not a mistake. By distracted coding I mean that situations like this happen: you intend to write a piece of code which does something specific. The code is motivated by certain happy cases. You start coding it and get it into a state in which it runs but doesn't quite do what was intended. Then you get completely distracted by some interruption. You forget that the code hadn't been completed; you mistake the remembered intent for the completion. You run the code and it carries out the intent on the motivating happy cases, and somehow fool yourself into believing it was done. Maybe Pike meant that it was a mistake to create that requirement. I don't hate the $HOME/cfg directory idea, but please call it $HOME/.cfg so I don't have to see it. :)

pxc 4y ago
> Someone like Thompson or Ritchie wouldn't consciously write a test for just the leading dot without being fully aware that it matches more than . and .. . Why not? Alternatively, who said the decision was 'conscious'? It doesn't take a dumb person to make a dumb mistake. Brilliant people get things wrong all the time, and anyone can be hasty or careless in a moment.
- kazinator 4y ago
  I believe I cover all your remarks with the discussion about distracted coding. If it was a coding mistake, it would have to have been something like that. It's not a coding mistake where some wrong identifier was used or other typo; coding the proper test requires more instructions. You have to check that there is either a 0 byte after the first '.', or else another '.' byte that is followed by a 0. Here is how someone could be distracted halfway through and forget to finish it. Suppose the code has a structure like this: for (;;) { if (getnext(name) < 0) break; /* code added to skip . and .. */ if (name[0] != '.') /* if it doesn't start with a dot, print it */ goto print; /* This can be continued here with more logic without changing the above line; But it would already skip . and .. with just the above line. */ if (name[1]) { /* two or more chars */ if (name[1] != '.') /* Dot followed by non-dot: print it */ goto print; if (name[2] != 0) /* Two dots, followed by non-dot: print it */ goto print; /* confirmed dot-dot */ } /* confirmed dot or dot-dot */ continue; print: puts(name); } And the code does have this structure: it tests for the . character, and branches forward if not equal. Whenever that bne branch is taken, the situation is correct. cmpb (r3),$'. bne 2f sub $8.,r1 br 1b 2: jsr r5,gstat br 1b So this could be corrected with further refinements by adding more instructions after the bne where the branch is not taken, without changing the prior instructions. If the behavior was indeed not intended, this would be a case of incomplete code. Incomplete code can happen by distraction. You turn your attention to something else, perhaps for the span of several days, and then don't remember the incomplete state. The brain had visualized the complete state, leaving a false memory of that having been done. On a related note, one element that is gapingly absent from all historic Unix sources is ... test cases! Compiler test cases, shell test cases, utility test cases, library function (and system call) test cases ... They are nowhere to be seen.

vrnvu 4y ago

I got me a copy of The Unix Programming Environment (1984) by Pike and Kernighan last year. It has plenty of hidden small design gems or anecdotes like this one. For example, why files don't need a \EOF char, it's implicit when you don't read more bytes the you have reached the end of a file... Unix design was about making things work (1) and simple (2).

chasil 4y ago
This book is online for free (three cheers for exotic spelling at archive.org). http://files.catwell.info/misc/mirror/the-unix-programming-environment-kernighan-pike.pdf http://files.catwell.info/misc/mirror/the-unix-programming-e... https://archive.org/details/UnixProgrammingEnviornment https://archive.org/details/UnixProgrammingEnviornment
cma 4y ago
I wonder if \EOF was around due to punch cards? You maybe didn't want an implicit EOF in case you lost the last card.
- int_19h 4y ago
  EOF was around because many early file systems only recorded the number of allocated blocks per file, so some other mechanism was needed to record the precise length in bytes in cases where padding with spaces was not acceptable.
  - bombcar 4y ago
    Exactly - think about a tape with multiple files on it - you want some way of knowing you reached the end of a file without having to seek all the way back to some directory.

csydas 4y ago

Maybe a dumb question but why do so many apps rely on dotfiles when /etc exists? I'm not making a judgement, this is an earnest question as even though it's meant for system config files, is there any reason that all app configurations shouldn't live there? If not in /etc, then at least /usr/etc? I'm sure there is some historical reason but some brief searching and I've not really come up with why dotfiles everywhere are preferable to a centralized configuration directory.

dooglius 4y ago
Multi-user systems, where things outside $HOME are not editable, and where different users may have different configurations.
ews 4y ago
I assume that because on true multi-user systems, syncing permissions between $HOME and /usr/etc/$USER may be a complete disaster.
- nmz 4y ago
  Back ups would require you to know which paths are actually yours and where, chrooting would be problematic.
CleverLikeAnOx 4y ago
Dotfiles are a per user application config. Other users of the same system are unlikely to want my idiosyncratic zsh setup. Hence the suggestion for $HOME/cfg in the article.
PeterWhittaker 4y ago
Apps can rely on both /etc (for system defaults) and on ~/.something (for per user defaults). If we used only /etc, then we would need per user entries there, which would be far more difficult, esp. with network-mounted home folders, especially when those are automounted.
- 4y ago

quickthrower2 4y ago

I recently learned about this "mistake". I always assumed the dotfile was some design feature by ancient "gurus" of UNIX rather than an accident. There is something nice and immediate about adding a dot to make it invisible to certain things (ls by default, the file explorers in ubuntu by default, etc.) A bit like file extensions themselves and the weight they carry in Windows. It sorts of balances in favour of immediacy of the function over "right way to do things", where the right way might be some kind of meta data for the file, or for it's folder. Funny thing about hiding, is what does it mean to hide? If you can ask your utility to show hidden things. It sort of means "things I reckon people don't wanna see, or shouldn't touch, unless they are willing to take a step to see it". A bit like a shibboleth where if you can't figure out how to see it, you are too dangerous/dumb to edit it, or even know about it. You could instead have security settings for that. Maybe you just don't give the user access to the files at all until they elevate from user to "poweruser". Which would be somewhere between user and superuser. Use chmod to set the permissions, instead of a dot filename format.

IncRnd 4y ago
> I recently learned about this "mistake". I always assumed the dotfile was some design feature by ancient "gurus" of UNIX rather than an accident. He said the decision was certainly a mistake, which is an error in judgement, and pretty sure it was an accident, which is an unexpected incident. It is a mistake to conflate the two.
- quickthrower2 4y ago
  I am not sure whether this was a mistake or accident based on those definitions, it is a close call. But thinking in those terms is certainly good for clarity of thought, so thanks!
pxc 4y ago
> Funny thing about hiding, is what does it mean to hide? If you can ask your utility to show hidden things. It sort of means "things I reckon people don't wanna see, or shouldn't touch, unless they are willing to take a step to see it". One thing I like about hidden files via the dot prefix is that I feel like it makes clear that the files are hidden only by convention. It's not a security feature, it's just a convenience to help spare you the mental overhead of witnessing the clutter.

croes 4y ago

>I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake. So it's just an assumption and so the title is misleading

unixbane 4y ago

this post is a good example of how un*x hippies with their fried brains from too much drugs* realize one unit of common sense after aeons of contemplation. just like with generics in go. in fact, go itself is just decades of C users very slowly conceding to the idea of basic hygiene. it took them decades to come up with something which is essentially just what was already available in the 90s (pascal, fortran, ada, basic, later java 1.2 or so which also had green threads), but with stuff done a certain way so the boomers can be like "oh see, we did this minor syntactic change THIS way, checkmate, pascal"), in other words they want to have their say in everything * im not joking, this is what un*x culture appears to essentially boil down to. boomers were all hippies in the 70s despite presenting themselves as "austere" and "mature" "wise" individuals now, which had the unfortunate side effect of too much drugs. further research is needed to clarify whether brain damage is caused by drugs or un*x any encoding in file names at all is a mistake. this includes character encodings too, which may sound like a non-sequitur but its not. in fact, files should only have unique identities, not names. names should be metadata. folder hierarchy should just be a user defined data structure that can reference these said "files". anyone who tries developing their own OS without copying extremely idiosyncratic un*x ideas and without being bogged down by the overhead of assembly language or C quickly learns this. an example of youngins discovering this is IPFS (and subsequently implementing it on top of broken un*x)

arboles 4y ago
lmao based
qbasic_forever 4y ago
This is an AI generated comment, right? You didn't get a job at freaking AT&T Bell Labs by being a pot smoking hippie. They were the squarest of square professionals--suit, tie, the whole bit.
- unixbane 4y ago
  no, it just doesn't fit into your two categories of posters here on HN

kazinator 4y ago

This is reminiscent of John MacCarthy pooping on NIL. "The unexpected appearance of an interpreter tended to freeze the form of the language, and some of the decisions made rather lightheartedly for the ``Recursive functions ...'' paper later proved unfortunate. These included the COND notation for conditional expressions which leads to an unnecessary depth of parentheses, and the use of the number zero to denote the empty list NIL and the truth value false. Besides encouraging pornographic programming, giving a special interpretation to the address 0 has caused difficulties in all subsequent implementations. " (History of Lisp, 1979)

gryn 4y ago
the explanation for pornographic programming are very interesting: https://stackoverflow.com/questions/8547142/what-did-john-mccarthy-mean-by-pornographic-programming https://stackoverflow.com/questions/8547142/what-did-john-mc... > 0==() has been the emoticon for pornography since 1958. > The fact that too many implementation details were leaking at a higher level, i.e. showing up too much > Code that uses intimate knowledge.

transfire 4y ago

100% I’m on the verge of abandoning the home directory. I’ll put My files elsewhere and leave home to the apps. I thought XDG would surely solve this problem but it’s painfully clear now that most developers just don’t care. `node_modules` and `snap` are good cases in point. They didn’t even bother hiding them! LOL

smm11 4y ago

However Apple does it is best.

PeterWhittaker 4y ago

Pike may be right that it was a coding error (but cf comments elsewhere re the unlikelihood that Ritchie, e.g., wouldn’t have thought of those other cases), but I think he’s wrong about it being a mistake. I love dotfiles. When I list a folder, I don’t want to see all the cruft, I want to see the key stuff. Sometimes when I organizing something new, I use .directoryName to hide things temporarily. git is one of my favourite examples: .git hides stuff I do NOT need to see every day, leaving behind the things I am actually working on, the things I care about. Besides, it is so easy, once one has CLIed a while, to find (no pun intended) and/or account for dot files when you need to.

llanowarelves 4y ago
If that wasn't already the behavior, people might do things like prefix with "_" or "__" to sort all the cruft to the top. "__git".
ablob 4y ago
I still think it is a mistake which you may be repeating by conflating two concepts: - The location of a file - Standard visibility of the file If you hide something (like a folder) temporarily and refer to it through a script, you have to go to the script and change it once you decide that you don't want the folder hidden anymore. The script is now coupled to not only the location of the resource, but also its visibility. There is no reason to conflate the two concepts. Git folders can still be hidden by default without requiring adaptation to path names. I'd argue, what you're loving about dotfiles is not the presence of the dot, but the concept of visibility levels on files.
- account42 4y ago
  But combining these concepts is useful - with a .dot you know based on the name alone if it is hidden or not. If there was a hidden flag then whether or not a file is hidden is itself hidden. E.g. you could have something referring to a file by any name which your file browser / ls does not show and but the file is still there and will be loaded - that's unnecessarily surprising.

noncoml 4y ago

First of all, “A lot of other lazy programmers”. That’s cringe. I don’t care who you are, that’s not a way to talk. Secondly, I think we have all been there. We introduce a bug in an interface/API but then the users of it start depending on this behaviour and before you know it it’s a feature and it’s impossible to fix without breaking the world.

cmrdporcupine 4y ago
He's obviously a very smart guy and a pioneer and a much more accomplished person than me (or most of us), but Rob Pike seems to make a habit of arrogantly talking down about other people's intelligence or skill: Re: Go “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” -- Rob Pike I agree it's really a cringe way of approaching people. In this (dotfile) case there may have been some self-deprecation in the comment though, so it's frankly hard to get too miffed about it.
- shepherdjerred 4y ago
  I think he very accurately described the problem Go is trying to solve which is how do you make new grads productive? In my experience at AWS people that graduated didn't understand the languages we used. This leads to a bunch of problems, and makes it's easy to write very bad, unmaintainable code. Lots of needless class hierarchies in Java, or a misunderstanding of `this` in JavaScript. Go solves the problem perfectly.
  - cmrdporcupine 4y ago
    Never had that experience at Google. New grads and interns always seemed sharp. Might just be the superior quality of education out of U of Waterloo, or the hiring bar at our site, or both. I enjoyed working with them. With new grads, I generally didn't have to teach coding knowledge. It was more about transmitting wisdom around best practices, estimation, architecture, etc. If anything, to me Go makes a lot of things harder that could be simpler. Lack of generics means boilerplate. Eschewing test frameworks means boilerplate. The structural typing stuff is exotic (but neat I guess) and not familiar to most new programmers. The actor / CSP type concurrency stuff is also exotic and not familiar to most new programmers. I don't see how it's a language for new programmers. It also seems very much like a rehash of the concepts they had in Limbo so I actually don't find it honest for him to be claiming it was designed for this purpose (to simplify programming). Instead it feels very much like they had a hammer in search of a nail, an itch they've been scratching since the Plan9 days. And that's fine. I just don't buy this pitch about its market niche and the stuff about the relative intelligence of programmers is gratuitous. I've seen some very smart new grads produce amazing Rust code for example.

mikl 4y ago

I agree that it’s annoying that so much junk accumulates in the root of your home dir. But any consumer-facing OS will need some sort of mechanism of hiding/protecting configuration files/logs/etc. from deletion by clueless users, like how macOS has started hiding ~/Library by default.

int_19h 4y ago
The article points out that a better way to do this would be to designate one particular folder for configs, and then that alone could be hidden if desired. But we have what we have instead because a "convenient" hack was misappropriated.
- mikl 4y ago
  Yes, but it also claims that hidden files in general were a mistake and mentions how Plan9 not having hidden files was learning from this mistake.
  - bombcar 4y ago
    Config files are only one subset of possible dotfiles (a common one to be fair).

hk1337 4y ago

A happy little accident

coldtea 4y ago

>How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about 40 years ago? Not many? In the sense that, considering several UNIX and C design issues and footguns, the dotfiles are the least of our worries (compare e.g. to C buffer overflows or shell escaping rules, to name but two)... I also don't particularly like the repeated ditches at "lazy programmers" - isn't the whole "New Jersey" style [1] heavy on laziness? In fact, if those "lazy programmers" were given OS level-APIs and libs doing the right thing about dotfiles, they wouldn't have recoded them on their own in their programs... [1] https://en.wikipedia.org/wiki/Worse_is_better#New_Jersey_style https://en.wikipedia.org/wiki/Worse_is_better#New_Jersey_sty...

doctor_eval 4y ago
That link is awesome. Thanks.
pantulis 4y ago
It's not my intention to second guess Ken, but at least in terms of performance I'd say that the current user home directory structure would bet a hit in the buffer cache since Unix got filesystem buffer caches. In terms of wasted CPU cycles, it's another story but hey these are the days of using npm packages to basically do a string comparison.
ParetoOptimal 4y ago
Not a fan of worse is better. I have some rough thoughts on expressing why: > This leads one of the major cognitive biases in software development where people speak of tradeoffs without establishing they are Pareto Optimal, and wrongly arriving at the conclusion “nothing more can be done without a huge effort”. https://www.paretooptimal.dev/pareto-optimality-and-software-development/ https://www.paretooptimal.dev/pareto-optimality-and-software...
- coldtea 4y ago
  >Not a fan of worse is better. That's ironic given your handle on HN :) >This leads one of the major cognitive biases in software development where people speak of tradeoffs without establishing they are Pareto Optimal, and wrongly arriving at the conclusion “nothing more can be done without a huge effort”. Well, part of the idea is to do the "pareto optimal" work not just implementation-wise, but also in checking whether the tradeoffs are pareto optimal (pareto-ception). Thus, avoid "analysis paralysis"

codedokode 4y ago

Adding . and .. was a mistake by itself. I never needed them, but always had to write conditions to skip them when traversing the file system. Also, dotfiles don't work well with masks because `*` doesn't match dot-files, and `.*` match all dotfiles including . and .. which causes many programs to fall into endless recursion (for example, `du -sh .*`). Everything related to dotfiles in Linux is done wrong.

GekkePrutser 4y ago
Wildcards are entirely shell-dependent so blame the shell you're using, not Linux :)
- debugnik 4y ago
  glob and fnmatch are C functions defined in POSIX though.

im3w1l 4y ago

A long time ago I liked listening to original soundtracks for games. Winamp had a plugin that would play .psf (et al) files. There were files that contained the extracted code from games for playing the music. The plugin had a tiny builtin emulator that could run the relevant parts. No graphics or input I suppose. One soundtrack I really liked was .hack, including the leading dot. Given that "hack" part and the overall theme of the games I assume the initial dot was quite intended. But what the creators could not have foreseen was that their soundtrack was missing from the majority of psf mirrors (but some had it obviously). I guess some part of some stack ignored dot-prefixed files when doing the mirroring. Anyway, although I'm usually opposed to inband signalling, I am a fan of dot-prefix for hiding. Filenames already have so many special corner cases that you would have to treat them very carefully even without this one. The fact that it is embedded in the name means that any system can roundtrip hiddenness - something that cannot be said for metadata.

swellguy 4y ago

He's probably just ignorant of how bad things can get. Hidden files in a home directory is a lot better than what other operating systems came up with (random directories and the dreaded registry). I'd call it a win - the search over a home directory inode is not going to bother anyone either way.

heikkilevanto 4y ago

Dotfiles are useful, not only in the $HOME directory, but in every project that has a .git directory, and many other ways. Maybe it was a design accident, but it has got stuck, and many old greybeards like me are used to it, and find good use of it.

lofatdairy 4y ago

>I was wondering why this post had so many comments. Then I found out it was posted on proggit/HN. The discussions there were hardly interesting, however. For the curious (was a bit annoying to find since gplus is down now and all links redirect to a different subdomain): https://news.ycombinator.com/item?id=4331855 https://news.ycombinator.com/item?id=4331855

alpaca128 4y ago

> my home directory has about a hundred dot files [...]. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge. Nothing against software efficiency, but those hundred loop iterations checking a string aren't going to be the big time-waster of your daily life.

labrador 4y ago

I feel consternation about symlinks on Windows. I find them extremely useful, but you never know which program is going to ignore them and which program is going to follow them. They're inconsistent. Plus you can't tell by looking at files if they are symlinks or not because they have the same icon as shortcuts. I recently managed to crash Visual Studio 2022 because I had a symlink to a drive with a hidden $RECYCLE_BIN on it. If you copy files in Windows the system will copy the contents of symlinks, however many backup programs will not follow symlinks.

ggm 4y ago

I find the best way to read a Pike statement is to take it as a challenge to your own strongly held belief. I like .dotfiles behaviour and ls -a does not distress me. But, he makes a case it was not deliberate and probably less beneficial than we think. So I look at that as a reframing: do I have a good rebuttal? No. I have my own muscle memory and comfort factor, but that's all. How would I think if dotfile hiding didn't happen? Hiding . & .. is arguably as silly. It's not like they can ever not exist but why hide them?

cvccvroomvroom 4y ago

Dotfile synchronization is a necessary evil. At work, we have a dotfile synchronization system that contains an infrastructure-level yml file of what to save, what are history files, and what to exclude. Every time a modification is made, it saves a revision. You can have multiple dotfile environments also that completely swaps them out. On the work laptop, I have google drive saving a .dotfiles dir with symlinks into them.

p4bl0 4y ago

All my important dotfiles are symlinks to ~/local/etc, which is versioned. $ ls -R1 local/etc local/etc: bash_aliases bashrc gitconfig inputrc nanorc ocamlinit ssh unison XCompose local/etc/ssh: config local/etc/unison: backup.prf

andix 4y ago

Dot files are much better than hidden files on Windows (and before DOS). There you need additional attributes to hide files. And hidden files seem to be an important thing. Some things you need to hide from the end user.

saba2008 4y ago
>Some things you need to hide from the end user. De-emphasize - maybe, hide - no. Garbage pile that is average Linux home directory is pretty much result of 'out of sight - out of mind' practice, enabled by dotfiles being hidden. I wish Linux settled on single `~/System/` directory, mirroring `/` structure. On the other hand, dotfiles convention is useful for meta/"parallel" data, `.git` being prime example - something tighly linked with abitrary file structure.
- andix 4y ago
  Sure, the dot files in ~/ are a mess. It would be so much cleaner if the convention would've bin similar to /var, /etc, and so on. ~/.var/cache or ~/.etc/