It’s a superset of python, so valid python should run fine. Imports into your shell are doable, too – for example, I import path.Path in my xonshrc, so it’s always available when I hit the shell. I don’t often have to use Path, because regular shell commands are often more straightforward. But when I do, it’s nice to have it already loaded. Granted, that could get kooky, depending on what you import and execute.

You can associate/shebang Xonsh with .xsh files, or run “xonsh foo.xsh” - and that works like “bash foo.sh” would, except using xonsh syntax, of course.

It’s not Bash compatible - copypasta of scripts may not work out. But it’s a good shell with some typical shell semantics.

there are some great plugins, too - like autovox, which allows you to create python venvs associated with specific subfolders. so, cd myproject does the equivalent of cd myproject; . path/to/venv/bin/activate.

overall, there definitely is some jank, but it’s a great tool and I love it.

I like nushell, but I love xonsh. Xonsh is the bastard love child of Python and Bash.

it can be thought of as:

• try this statement in Python
• if there’s an exception, try it in bash.

Now, that’s not a very accurate description, because the reality is more nuanced, but it allows for things like:

for file in !(find | grep -i '[.]mp3^'):
    file = Path(file.strip())
    if file != Path('.') and file != file.with_suffix('.mp3'):
    mv @(file) @(file.with_suffix('.mp3'))

Now, there are things in there I wouldn’t bother with normally - like, rather than using mv, I’d just use file.rename(), but the snippet shows a couple of the tools for interaction between xonsh and sh.

• !(foo) - if writing python, execute foo, and return lines
• @(foo) - if writing sh, substitute with the value of the foo variable.

But, either a line is treated in a pyhony way, or in a shelly way - and if a line is shelly, you can reference Python variables or expressions via @(), and if it’s Pythony, you can execute shell code with !() or $(), returning the lines or the exact value, respectively.

Granted, I love python and like shell well enough, and chimeras are my jam, so go figure.

tragedy of the Commons, with external pressure to boot.

I like to think about ethics. I still pirate some random stuff here and there, but one thing I like to do is make sure I’m getting some money to the creators of what I’m enjoying, skipping the middle man as much as can be.

this is mostly only relevant with music, but if I can buy an album or song directly from the artist, that’s awesome. it not, i try to five what service benefits them most.

install Linux. then it works.

edit: seriously, though. AMD GPUs are what it’s like in Linux when a vendor plays nice. It’s the Real Linux Experience™️ that you get when using supported hardware.

You can do Linux if your situation meets these criteria:

• your hardware is supported. it likely is, but check. Usually running a live usb is sufficient.
• The proprietary software you want to run is supported in some stable way - like, platinum steam support, or the developer supports and intends to continue supporting Linux. do dual boot temporarily and make absolutely sure.
• you are psychologically capable of declining to try to fix everything. While Linux just works for me, I’ve learned to recognize escalating effort in getting some new cool piece of software or hardware to work. wait until what you want is at least in beta. aside from that, it’s just not supported. Don’t frozzle the frimfram as /u/linuxminordeity told you to, because after that, you’ll have to bidnap the uperpon. …and on and on. just accept that people are working on it and it’s not ready. contribute somehow, if you feel like it. but accept. If it can’t be installed through typical channels (website package for linux, the repositories, or flatpak) it just doesn’t work.

tbh, it sounds like you don’t want to have to think about and test it. …and if that’s true, then you shouldn’t be switching operating systems if you can reasonably avoid it.

yeah. poorly worded.

Grow up. he did.

shrug