manually call the others
Yeah, most distros will set up source
chains to make things nicer for users.
manually call the others
Yeah, most distros will set up source
chains to make things nicer for users.
Yeah, I’d write this as a single update
script with options to update vimplugins
or update pkg
or update all
.
I see that you want it to be a function so you can get the chdir as a side effect, but mixing that with updating doesn’t make sense to me.
When in doubt, ~/.zshrc
. It’s the right choice 99% of the time. Otherwise, there’s a chance you fuck up scripts you’ve installed which assume no shell options have been changed in non-interactive contexts.
What kind of functions do you write which you share between your scripts? Generally if I’m wanting to reuse a non-trivial function, I extend the functionality of the first script instead.
Select the color which matches the steps before filenames ((non-)login and (non-)interactive), then follow that arrow the rest of the way. There’s more colors in Bash because Bash makes a distinction between remote and local shells.
Another way to look at the same data for Zsh (note: $ZDOTDIR
will be used instead of $HOME
if it’s defined at any step along the way):
File | neither | interactive | login | both |
---|---|---|---|---|
/etc/zshenv |
x | x | x | x |
${ZDOTDIR:-$HOME}/.zshenv |
x | x | x | x |
${ZDOTDIR:-$HOME}/.zprofile |
x | x | ||
${ZDOTDIR:-$HOME}/.zshrc |
x | x | ||
${ZDOTDIR:-$HOME}/.zlogin |
x | x | ||
${ZDOTDIR:-$HOME}/.zlogout |
x | x |
One confusion on the Bash side of the diagram is that you see branching paths into ~/.profile
, ~/.bash_profile
and ~/.bash_login
. Bash will use for ~/.bash_profile
, ~/.bash_login
, and ~/.profile
, in that order, and execute only the first one that exists and is readable.
Optional crash reporting was merged. Most of the backlash in the PR is about the significant dependencies (Google’s BreakPad) which were pulled in with it.
However, by default Audacity isn’t built with it, you need to specify a CMake with the URL to send data to. No distros that I know of enable reporting.
CSS is turing conplete.
What about adding the flags last?
rm deletethisrepo -rf
You could still NAT between v6’s though.
It’s probably the biggest deal for games running in xwayland
That’s a latrine. They’re talking about a fancy light fixture.
How is it compared to wofi?
If you say “a 10d10”, I know what you mean, but “10d10” is definitely the sum of 10 10-sided dice.
More people should be like you.
Exact same. Sway’s 1.0 release was March of 2019, and it did everything I needed.
Even playing games on my desktop, Xwayland worked fine for me.
Nope. If you open a nonexistent path and you have permissions to write to that directory, then that file is created.
8GB memory + two Firefox profiles makes things difficult on my laptop.
Others have mentioned disk usage and desktop integration. There is some truth to them, but shared runtimes keeps disk uasge down (although worse than native apps). Desktop launchers now search /var/lib/flatpak/exports/share/applications
by default, but I’m still having issues with themes in one or two niche apps.
Trust is the big one. The benefit of your distro’s packages is that they are maintained by a limited number of maintainers. Flatpaks have a much, much larger number of maintainers, which is where sandboxing comes in. Flathub now marks apps with lax permissions as “potentially unsafe”, which is a huge step in communicating this to the average user.
Most desktop apps can get away with having next to no access, as long as they support the appropriate XDG desktop portals.
Ultimately, your mileage will vary, as there are many classes of application which are ill-suited to being sandboxed. Program launchers, programming languages, IDEs, file managers are a few.
zsh-syntax-highlighting
There’s also a fork called fast-syntax-highlighting, I use it.