linuxPIPEpower

well I guess a way to test would be to create a new directory and copy or create some files into it rather than using a working directory where there are unknown complexities. IIRC dd can create files according to parameters.

Start with a single file in a normal location and see how to get it to output the correct info and complicate things until you can find out where it breaks.

That's what I would do, but maybe a dev would have a more sophisticated method. Might be worth while to read the PR where the feature was introduced.

Also kind of a shot in the dark but do you have an ext4 filesystem? I have been dabbling with btrfs lately and it leads to some strange behaviors. Like some problems with rsync. Ideally this tool would be working properly for all use cases but it's new so perhaps the testing would be helpful. I also noticed that this feature is unix only. I didn't read about why.

it would be that du AND Dolphin filemanager would ignore those files, and eza would not. Which its hard to believe for me.

Although only 1 of various potential causes, I don't think it is implausible on its face. du probably doesn't know about git at all right? If nautilus has a VCS extension installed I doubt it would specifically ignore for the purposes of calculating file size.

I have found a lot of these rust alternatives ignore .git and other files a little too aggressively for my taste. Both fd (find), and ag (grep) require 1-2 arguments to include dotfiles, git-ignored and other files. There are other defaults that I suppose make lots of sense in certain contexts. Often I can't find something I know is there and eventually it turns out it's being ignored somehow.

aside from the subject of the post: the ones I miss when it's not available are git status/ignoring, icons, tree, excellent color coding.

Here I cloned the eza repo and made some random changes.

eza --long -h --no-user --no-time --almost-all --git --sort=date --reverse --icons

Made some more changes and then combine git and tree, something I find is super helpful for overview:

eza --long -h --no-user --no-time --git --sort=date --reverse --icons --tree --level=2 --git-ignore --no-permissions --no-filesize

(weird icons are my fault for not setting up fonts properly in the terminal.)

Colors all over the place are an innovation that has enabled me to use the terminal really at all. I truly struggle when I need to use b&w or less colorful environments. I will almost always install eza on any device even something that needs to be lean. It's not just pretty and splashy but it helps me correctly comprehend the information.

I'd never want to get rid of ls and I don't personally alias it to to eza because I always want to have unimpeded access to the standard tooling. But I appreciate having a few options to do the same task in slightly different ways. And it's so nice to have all the options together in one application rather than needing a bunch of scripts and aliases and configurations. I don't think it does anything that's otherwise impossible but to get on with life it is helpful.

hmm I didn't think to actually test the results. But now that i do, I get same sort of descrepency.

How about this?

eza --long -h --total-size --sort=size --no-permissions --no-user --no-time -a --blocksize --binary

that works in a couple test directories with the column Blocksize.

Also it might (??) be ignoring according to your gitignore if that is relevant? Or behaving differently wrt symlinks?

Seems like the default behavior should be whatever is most expected, standard and obvious. Or else give user a hint.

I find this in the repo, is t relevant?: bug: Inconsistent Size Display in `exa` Command for Large Files (1024 vs. 1000 Conversion) · Issue #519.

don't forget eza --version. I find it is not updated quickly in every distro. See changelog; it looks like there might have been a relevant update as recently as [0.18.6] - 2024-03-06. Actual my system is only updated to 0.17.3 now that I check this too.

I guess it would be too much to get a set of metronomes eh.

soooo how do I access it?

Not everyone can have 2 computers for all kinds of reasons.

Everyone do you best. Prioritize your data and take stronger precautions for the most important.

Lucky Backup is a fantastic piece of software. It is the perfect amount of GUI to spread over rsync.

In a conventional set up you have tabs which are collected into windows. When you close a window, all tabs it contains are closed. You can do other things on all the tabs in a window, like reload, unload, bookmark, etc.

Windows can be divided among workspaces arbitrarily or can be on all workspaces. Workspaces can be created or deleted on the fly. Windows which are in a deleted workspace do not close, they just move to an adjacent workspace. Though you could probably script otherwise if you wanted.

From your screenshot am thinking your system is just like having all tabs in a single window in a single workspace?

in case you don't know, you can discard tabs natively without an extension in FF now by going to URL about:unloads. it's a newish feature in the past year or so. much more rudimentary than Auto Tab Discard but gets the job done with one less extension.

I like light themes and agree that they can be done well. Overall my problem with dark themes is they are too low contrast everything melts into everything else. Who doesn't want a distinct border around a window?

I agree the debian website is exremely confusing. I was wandering around for ages with a dozen tabs open trying to find the actual download link I need.

I dont know how to code but i have made contribs on repos. For documentation and stuff.

Some repos are very complex and some are simple. It is typically roughly corrolated to size: larger projects = more complex. And then it depends on the language/platform/toolchain being used. Some of them can be very ellaborate. If you dont typically work on that kind of project the set up can be very difficult as you are starting from scratch with dependencies, might need dev versions, can be a whole thing.

Also there are some things which are organizational choices made by the maintainers. A couple of times i was unable to contribute to docs because they werent seperated from the rest of the project and just to edit markdown files you had to install a whole dev toolchain and who knows what. I gave up before getting anywhere. Whereas others have different components segregated nicely.

Then there is quality control stuff having to do with testing, formating and such. You might only find out about that once you've got through everything else and time comes to make a PR.

Start out by using git and github or alternative for yourself to learn the basics. Then pick a smaller, explicitly beginer friendly project to make some minor contributions. Something with a few maintainers and regular contributions from others is generally a good balance. Look for an updated CONTRIBUTING file or equivilant section in the documentation.

I think making a few markdown contribs first is probably advisable even for programers because most of the time it is more simple.