You are trying to use a software built from a different operating system, by definition you have to tinker, unless someone already did it for you. That’s how compiled code works
The only way to avoid tinkering is using native applications. With the exception probably of proton, as valve tinkered for the users
proton never works for me so thats out of the question most likely
if you perhaps have an easy to understand (not KISS but actually easy to comprehend) solution, guide, steps or otherwise im happy to listen, i dont mind distro for the most part
I meant proton as an example of a product where someone else did the tinkering for the users that want to use software compiled on a different operating system.
My suggestion is to search for an alternative of the program built for linux. That’s the only way you have to avoid tinkering.
Because using something compiled on a different OS is tinkering
Proton is designed only to be used within Steam, use something like wine-ge-proton outside of Steam (this won’t solve your problem, but keep it in mind)
Laptop: NixOS, mostly to try it out. So far I’m really liking it. Fileserver: Open Media Vault (it’s Debian with a cool web UI) Container servers: Ubuntu, but I’m thinking of switching them out. Still contemplating between Rocky or Debian.
For the driver quality issues, make sure to filter out Windows vs Linux reviews. Intel has historically been way better under Linux than Windows, and they use translation layers under the hood on Windows which is something we’re used to on Linux. I heard it’s a bit better on Linux.
Kinda like Windows vs Linux for AMD cards, sometimes it’s just better on Linux. Only NVIDIA have mostly identical drivers for both platforms and thus is about on-par with performance and stability.
Thanks for the input. Yeah, my research has been more linux specific. My feeling was that Intel would perform well under linux, but browsing around most of what I’ve been finding are posts from a year ago, and nothing more current. I’m assuming that the cards (and more specifically driver support) would only get better in time (assuming it’s not the next optane… haha).
I installed it about a year ago. It worked fine in my (extremely) limited testing. I daily-drive MacOS and had recently got a MBP, so I figured why not give it a spin on my old Air as I’ve been supporting the project since its inception. I only used it for maybe five minutes. It seemed reasonably polished to me.
I have an iPad Air tucked into a leather couch pocket for just this reason. I pull it out and jump on Lemmy when we pause for my partner to go to the bathroom or make a snack. Sometimes, you just appreciate a bigger screen.
Funny you ask, I was trying to book an appointment for a local company on my phone the other day and it wasn’t rendering properly. It’s crazy to me in this day and age but it seems that there are still companies that have non mobile friendly websites. It’s happened a lot lately too, tried to order some food and the site used it’s own process for delivery, and didn’t render worth a crap on mobile. Basically a ton of little reasons why I want something like I describe.
Personally I opt for ‘show in desktop mode’ in my browser when that happens. Hasn’t failed me yet but I imagine it will with some weird site I visit one day.
Are you just using it for random web browsing, if you’re looking things up?
If so, and assuming since you want to get rid of macos you aren’t using the apple ecosystem? imo a macbook seems wildly overpriced for what sounds like light, occasional usage? I have been considering a macbook myself, so this isn’t just applehate or anything. It just sounds to me that something significantly cheaper would fit your usecase still?
I put a couple use cases above on another comment, but as I’m reading through these another one popped into my head. I have a steamdeck with controllers as my media center, the other day I was playing a game and wanted to look something up on the wiki for it. I got it done on my phone but it was a ton of pinch zoom, search page and it was just tedious. So add that to the use cases.
As for macos, I am not in the apple ecosystem at all, I use a macbook air for my day job and it’s serviceable but I’m just a linux guy really. If I can get KDE on it, then even better. I’ve been using KDE since slackware in the late 90’s.
The macbook air is handy though, when I have to go to the office (occasional) I don’t have to charge it and it’s small enough to carry everywhere.
Being honest here, I actually went down the chromebook route first but then I realized that to get a chromebook that uses a snapdragon cpu, and has a small formfactor, with linux support was actually a difficult combo, and if I did find one, there is a lenvo thinkpad for example, it was like $1000 or so.
Rebuild all dkms and kmod drivers, specifically your wireless driver. iferror, reinstall your kernel and firmware (if using firmware) again and allow mkinitcpio to finish and update grub/systemd-boot entries.
Note that it is recommended to use “./” before a raw * in globs to avoid filenames beginning with “-” being interpreted by the command as special arguments (this is not necessary in the above example, but it is a good habit). See dwheeler.com/essays/filenames-in-shell.html#globb… for more info. e.g.:
<span style="color:#323232;">touch ./-laR
</span><span style="color:#323232;">
</span><span style="color:#323232;"># Bad ls command:
</span><span style="color:#323232;">ls *
</span><span style="color:#323232;">
</span><span style="color:#323232;"># Good ls command:
</span><span style="color:#323232;">ls ./*
</span>
having it put each name in quotes should be fucking trivial
This is effectively what happens, except that it’s actually more robust than that, since it also accounts for names with quotes and other special characters. Glob expansion does NOT output file names into the shell; it passes them as arguments to the command with no further shell processing. Arguments can contain any special characters.
Not sure why you’re seeing this behavior. Are you doing something with these file names before passing them to mv? Storing them in variables? Saving them to files?
Note that it is recommended to use “./” before a raw * in globs to avoid filenames beginning with “-” being interpreted by the command as special arguments
Jackpot! I think! Based on OP’s reply to me, this is almost definitely the real problem:
mv *.jpg /mnt/Example/Pictures
Where it will then die with an error like mv: invalid option – ‘1’ depending on the contents of the current directory.
mv ./*.jpg /mnt/Example/Pictures works fine, though, so thank you for the practical solution. I’m still disgusted there’s any filename that gets treated as… not a filename. That broken stair might be older than I am.
Ahhh. That’s a confusing thread, with a couple confounding factors.
The OP in that thread is attempting to a batch rename, which is out of scope of the mv command.
If you are NOT trying to change the name of the file, I recommend always making the last argument of mv your destination directory, rather than the destination file. This is strictly mandatory if you are moving multiple files.
OP in that SO thread used the filename as the destination path — a filename which did not exist, and therefore could not be resolved by the wildcard. And if it had existed, the move would have failed. Because of that, mv /data/*/Sample_*/logs/*_Data_time.err /data/*/Sample_*/logs/*_Data_time_orig.err is not a valid command.
OP cannot accomplish what they want with a single mv command. They would need to use a loop or something like find.
I agree that the lack of universal consistency in how commands handle arguments is unfortunate. There’s no way around that without reinventing the entire OS. Many commands let you pass – as an argument to signify that any subsequent arguments should not be interpreted as options even if they begin with -. But that’s entirely up to the implementation of each program; it’s not a shell feature.
Future OS designers: consider typed arguments. Abandon all legacy cruft.
There’s no way around that without reinventing the entire OS.
Disagree. If wildcard expansion is not a feature of the tool, it shouldn’t be up to the tool to shape how each expanded input is passed. Some hideous escape syntax ought to force *.jpg to appear as “-a.jpg” instead of -a.jpg, once it reaches mv.
Instead * is acting as a cheeky little ls alternative, minus any degree of formatting control, and piping actual ls input into mv is similarly fraught with complications.
The reason these are equivalent is because quoting (and expansion, and globbing) is processed in the shell. The shell then passes the evaluated string as an argument to the tool. All of those evaluate to the same string, so they look exactly the same to the ls command.
What is the solution if there’s a file name that matches something the tool thinks is an argument? What would the correct behavior be?
The only solution is to include some way to communicate to the tool what each argument is. In practice, you could do ls – * and it would work even if the first filename was “-laR”. However, not all tools use the – convention. This is really core to the design of the OS, in that command arguments have no type.
All I can tell you is that, in my opinion, it’s ridiculous and terrible that old-school terminals haven’t been replaced yet with something more user-friendly and self-explanatory, at least in the same-machine user space. But given that they are what they are, some basic understanding of what shells do is required in order to use them, and you don’t have that understanding (I don’t fault you for this).
The key point here is that programs/commands always receive an array of string arguments, and it’s the shell’s job to translate your command line into that. Quoting (like in -m=“my message”), variable expansion (like $HOME) and various other things are processed by the shell and not the program, and the expectation is that the user knows this. So quotes are never visible to programs, and the upside is that programs never need to process such quotes - making these features universal without having various random bugs in each program’s implementation.
I’ve been using command-line programs for twenty-five years. “Basic” is not the issue, here. This is obscene edge-case behavior for what honestly should be a Hello World level example.
Thoroughly explicable causes do not make the outcome any less of a problem.
I’ve been using command-line programs for twenty-five years.
A general statement (not about you):
I’ve been using my human body for over 25 years (exact number withheld) and still don’t know shit about how it works and what it does. I don’t even know the muscle groups, which most people who care about their health learn. But I still use them. Years of experience don’t always translate to understanding and knowledge.
More specifically about you (and me): I’m sure you know a lot about how to use the shell, and I’ll absolutely bet you know more tricks than me to get shit done. But you still didn’t know about the quoting thing. I have a tendency to dig into understanding how shit works while not developing my actual skills in using them. You might have the opposite tendency. The best is somewhere in the middle, I think.
This is exactly correct. This is why I say it would require a whole new OS with no regard for compatibility with current systems.
As long as arguments are typeless and transmitted in a single array, there is no universal way to make programs distinguish between an option and file name that are identical. Full stop. No way. This has nothing to do with quoting schemes.
There are conventions to work around this (like –) but that is at the command level, NOT the shell level. It is not universal.
Is this some recent news that you expect us to have heard of? Your post demands context that is not easily understood (but it’s possible to understand through multiple reads)
What shell are you using?
I’m using bash (GNU bash, version 5.1.16(1)-release) and don’t observe this behavior:
<span style="color:#323232;">$ ls
</span><span style="color:#183691;">'first file.txt' 'second file.txt'
</span><span style="color:#323232;">$ cat </span><span style="color:#183691;">'first file.txt'
</span><span style="color:#323232;">this is originally named </span><span style="color:#183691;">"first file.txt"
</span><span style="color:#323232;">$ cat </span><span style="color:#183691;">'second file.txt'
</span><span style="color:#323232;">this is originally named </span><span style="color:#183691;">"second file.txt"
</span><span style="color:#323232;">$ mv </span><span style="font-weight:bold;color:#a71d5d;">*</span><span style="color:#323232;">.txt
</span><span style="color:#323232;">$ ls
</span><span style="color:#183691;">'second file.txt'
</span><span style="color:#323232;">$ cat </span><span style="color:#183691;">'second file.txt'
</span><span style="color:#323232;">this is originally named </span><span style="color:#183691;">"first file.txt"
</span>
It’s possible that whatever shell you’re using has a bug, but it’s definitely not universal. It’s also possible that this bug only affects builtins like mv and not non-builtin commands.
When I run into situations like this, I use the commands that work to write out a script. Eg, in your case the wildcard isn’t working with the mv command, so do something like this:
I saw that answer and was just offering another option. I am sure xargs might work, but you would need to test as you need a destination passed on each line. Back to my way, I have used it for a lot more than just the move command. I think I used it to do a chmod once where I wanted to check and make sure before I committed to actually running the command(s). You could also use find and the -exec option, which I think was also mentioned here.
Edit: also, you wouldn’t need to check each one, just the first few and last few to make sure the syntax is correct. Maybe do a wc -l to make sure it’s got the right number of entries and then let it run.
Can you run printf %s\n *.jpg in that same directory and share the result? I’m really intrigued. If there’s private information in there, I’d be satisfied with just a handful of lines showing the issue with private info replaced with ****s
Edit: also run alias mv to check whether you have an alias messing things up
printf %s\n *.jpg is just a list of filenames on newlines. There’s 75,000 of them. You’ll have to take my word for it.
Fortunately, GenderNeutralBro’s aside about using ./* instead of * works as expected. Could have been files beginning with _-. None begin with -, exactly.
Which you’d think would mean mv “thing.jpg” “other thing.jpg”, but no, it does mv thing.jpg other thing.jpg - and then chokes, because other is not a valid option or filename. Possibly after writing the contents of other thing.jpg onto the destination thing.jpg.
If any filenames contain characters like ; or &, you better hope the next word doesn’t look like a command.
Edit: also why would you ever want to move files like this, what is wrong with you
… like what?
The fuck do you mean, why would I want to move files in a terminal? Because I’m doing shit in a terminal! What, do you expect people to Super+E, find the directory they’re in, and drag-and-drop? I’m using tools that only exist in the command line.
I’m using whatever GNOME Terminal came with Linux Mint 20 by default. StackOverflow answers sound like any POSIX terminal will do this. I assume it’s standard behavior.
I mean with * where you have no control of the order of the files and you never explicitly say which files are being moved. “yeah, just rename files into other files, I don’t fucking care lol” is what your command does
I’m also a bit lost. From the final sentence “having it put each name in quotes should be fucking trivial.” OP seems to complain that filenames with spaces expand into multiple arguments. I can’t recreate this with this command in bash:
This command prints each argument in its own line. Replace *.jpg with whatever to prove it to yourself. Filenames with spaces show in full in a single line for me.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.