31–40 of 185 posts
Eh, I dunno. XDG is just some group or whatever, dropping config files in .programname is the de-facto community standard. If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.
> dropping config files in .programname is the de-facto community standard. Fuck you so much.
I completely agree! That's why I created this site: https://xdgbasedirectoryspecification.com . We need some place where people can immediately understand the practical benefit, and the minimum ask of their users. Of course, it doesn't help just to complain about the issue in a void, so I've also submitted like 10 PRs and filed quite a few issues. Projects like pnpm and Poetry took note, and now they comply! Someone'…
Why does the "fixed" example still list .profile? Why wouldn't the shell config live with everything else?
Admittedly, the ~/.bashrc etc. files should be there too - but I wanted it to look cleaner :P
Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths.
Windows also doesn't know what the dot at the beginning of a file/folder means. Instead, it and NTFS have something that's arguably better: a hidden file attribute `FILE_ATTRIBUTE_HIDDEN`[2], that's again settable/gettable when a file/directory is created or polled, rather than regex-ing for a full-stop.
The worst irony is Microsoft software creating dot-files and dot-dirs on Windows[3][4][5].
[0]: https://learn.microsoft.com/en-us/windows/win32/api/shlobj_c...
[1]: https://learn.microsoft.com/en-us/windows/win32/shell/knownf...
[2]: https://learn.microsoft.com/en-gb/windows/win32/api/fileapi/...
[3]: https://github.com/dotnet/sdk/issues/8678
[4]: https://github.com/OmniSharp/omnisharp-roslyn/issues/953
What I personally find more egregious are dotfiles and dot-dirs on Windows , created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a…
What I personally find more egregious are dotfiles and dot-dirs on Windows , created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a…
Is “..” the official way to get a parent directory on Windows? Or do they have some other API and the “..” is just a nod to UNIX compatibility?
I completely agree! That's why I created this site: https://xdgbasedirectoryspecification.com . We need some place where people can immediately understand the practical benefit, and the minimum ask of their users. Of course, it doesn't help just to complain about the issue in a void, so I've also submitted like 10 PRs and filed quite a few issues. Projects like pnpm and Poetry took note, and now they comply! Someone'…
The idea for your site is great. A quick suggestion: if you want everyone to immediately understand and sympathize with your cause, then use the tools that everyone knows in your examples. Using some long exa incantation risks alienating people that don't care about things like the latest trendy grep alternative. Just use: `ls -d .*` or `ls -a`
Exa is the latest, trendy ls alternative.
I don’t think you should remove the Exa example but you certainly should show how to use ls to do something similar for those people still living in the dark ages—ls was created in the 1970s and it hasn’t kept up with the times all that well [1].
I created an ‘ll’ alias for Exa using the Fish shell; obviously you make shell-appropriate aliases in Bash or Z shell:
function ll
exa --color always --long --no-user --no-permissions --all --icons $argv
end
What I personally find more egregious are dotfiles and dot-dirs on Windows , created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a…
Is “..” the official way to get a parent directory on Windows? Or do they have some other API and the “..” is just a nod to UNIX compatibility?
There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and .NET, with `System.IO.Path.Combine(String, String)`.
In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.
The solution is simple, stop messing your home and put personal data in /home/you/personal/ source code in /home/you/src/ The home is not a place supposed to store random "regular files"
On the contrary, that's exactly what it's supposed to be.
A lot of data is managed by software and by convection there is a dot before them
Unmanaged/Arbitrary data like random pictures or notes are personal and should end up in $HOME/personal
git repos are special managed data, thus they all end up in $HOME/sources
$HOME is supposed to let software to create their data folder and optimally without the dot
The data here includes config (which is read & write like data file)
$HOME/.config or XDG spec is monkey patch that do the wrong thing.
GUI file manager should open $HOME/personal as initial location
Terminal should open $HOME to let user access software's data file with shorter path (aka without .config/ )
You don't know if i am mad or being brilliant or simply brain dead, but i am making perfect scene.
What I personally find more egregious are dotfiles and dot-dirs on Windows , created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a…
Environment.GetFolderPath( SpecialFolder.LocalApplicationData)
~/AppData/Local
~/.local/share