Shell WTF

boomzilla

Do know you can switch to a different one without a reinstall - if you remove ubuntu-desktop you're still safe if you install kubuntu-desktop, ubuntu-gnome-remix, or if you want to go free some minimal server metapackage to ensure you keep the essentials.

Definitely had already removed the ubuntu-desktop stuff. After that adventure, I decided I could just live with it.

JBert

@Onyx said:

@RaceProUK said:
How many repos have the absolute latest anyway?

Arch fanboy entering the thread in 3... 2...

There's no latest like git clone git://git.savannah.gnu.org/bash.git ; cd bash ; configure ; make.

Filed under: No LFS users yet?

loopback0

@RaceProUK said:

Amazon Linux, but that sucks. Ubuntu sucks too, but less.

Way less.

CoyneTheDup

@sloosecannon said:

But if you're running a distro before that option

Y'all are making too much of my choice of examples. I'm trying to complain about a general misdesign issue in software in general, and you're focused on the fact that rm don't behave that way any more.

Okay, an example from another system, Hewlett Packard's MPE IV (not that any of you are familiar with that ancient artifact). There was this command in the manual, COND unit,SPACE, which the manual stated would report the free space on a disk volume. So I tried it on disk unit 1, which was a system disk.

What I got was a message something like this: The SPACE option is not applicable to system volumes. Assuming you meant, COND 1,ALL.

COND 1,ALL did a condense on disk space, it took 45 minutes, and no one could use the time-sharing system in the meantime; because (Duh!) the system disk volume is locked. Assuming it was necessary for the system to "fix" my command at all, assuming the ALL option was the absolute worst possible choice, of all the options it could assume.

Why would anyone design such a critical command to "correct" itself? Why would anyone assume that the "correction" should be the worst possible option?

Bad design.

The original rm -rf * was bad design. ~ expansion is bad design.

End venting.

sloosecannon

@CoyneTheDup said:

What I got was a message something like this: The SPACE option is not applicable to system volumes. Assuming you meant, COND 1,ALL.

COND 1,ALL did a condense on disk space, it took 45 minutes, and no one could use the time-sharing system in the meantime; because (Duh!) the system disk volume is locked. Assuming it was necessary for the system to "fix" my command at all, assuming the ALL option was the absolute worst possible choice, of all the options it could assume.

Ick, ick ick. That's horrible.

I agree entirely with your point - Was just pointing out pendantically that rm doesn't do that any more

Filed Under: pen<ins>dantically
Addendum: Goddamit discrouse, why must you make me copy raw to make the quote look right!?

Onyx

@JBert said:

There's no latest like git clone git://git.savannah.gnu.org/bash.git ; cd bash ; configure ; make.

That's what Arch's packer does, AFAIK.

PleegWat

Program command lines, and the fact they're inconsistent, is the root of the problem. A lot would be resolved if you could never refer to foo as a filename argument, but always had to use ./foo, //foo, or ~/foo, depending on which you meant. And //foo is probably a bad choice for an absolute path but I want to stay recognizable.

JBert

Close but not quite:

From a particular PKGBUILD script I looked at:

pkgver=2.1.1
source=("https://github.com/git-cola/git-cola/archive/v$pkgver.zip")

Yes I'm trying out Arch.

Other scripts might point to master of course.

CoyneTheDup

@sloosecannon said:

pendantics

Gee, what would we do without those?

sloosecannon

The world would be ~~missing something~~ ~~a horrible place~~ ~~somewhat depressing~~ much better off

EvanED

@CoyneTheDup said:

That's right, I said it: Better design. It is ridiculous to make the option that the user-almost-never-wants the default. "rm -rf" is the perfect example: How often, in this life, do you want a command to affect every directory on your system?

I... don't understand the argument. Are you arguing that rm is well-designed because the default (non-recursive) is the less destructive and the user almost never wants it? Because I disagree with that...

I can expand on my thoughts if anyone is curious, but I don't feel like spending 15 minutes typing out a violent agreement with someone. :-)

tar

@boomzilla said:

Definitely had already removed the ubuntu-desktop stuff. After that adventure, I decided I could just live with it.

You know you can install Ubuntu Server, and it won't install any desktop packages? Then you can apt-get install kde4 once it finishes...

Onyx

Pretty much what I did with my current Debian install. The difference being there's no separate "server" version (isn't Ubuntu Server's kernel a bit different? As in, different patches?), but you get asked about components you want to install and you can just uncheck "Desktop Environment".

tar

With the caveat that the only Debian box I have is a VPS, so I have no experience with a desktop on it, I have yet to find any discernible difference between Debian and Ubuntu.

RaceProUK

The difference is basically the desktops ;)

tar

Well, there you go, then.

Onyx

@tar said:

I have yet to find any discernible difference between Debian and Ubuntu.

Debian boots in about half the time Mint did. And Mint already removed some cruft from default Ubuntu as is. Also, testing repos seem to be ahead of at least Mint, if not Ubuntu as well. Even stable seems pretty up-to-date.

There are some downsides. Some of the Ubuntu-specific packages are pretty helpful, but so far I found Debian to be much snappier, and I prefer the fact that it gives me a basic system I can just add things on instead of a huge blob of stuff I don't need and then have to spend hours removing.

CoyneTheDup

@EvanED said:

I... don't understand the argument. Are you arguing that rm is well-designed because the default (non-recursive) is the less destructive and the user almost never wants it? Because I disagree with that...

Oh, no, no. I'm arguing that the implementation specifically for rm -rf * as it was done originally was a bad design.

When doing recursion, you most often want to affect the directory you are in and the directories below it. The designers of Unix assumed that * should include directory .. as well as all the other files in the directory. This means that the original version of rm -rf * would affect not only the directory you were in, and the directories below it, but also the directory above, and the directory above that, all the way to root (/) and then all the directories below that.

So rm -rf * meant, "delete every file on this system." When did anyone ever want to do that routinely?

As in the example I presented, it's like designing a cook stove to burn the containing house down, unless the user selects the Contain flame to stove-top option. You don't design cook stoves that way, because there are ways to use any cook stove to burn a house down--if you want to--but you almost never do. Instead, you design the cook stove for the usual case--keep the flame on the stove-top. If the user wants the extremely unusual case they can heap curtains on top to accomplish that.

ben_lubar

@CoyneTheDup said:

The designers of Unix assumed that * should include directory .. as well as all the other files in the directory.

Last time I checked, * didn't include any path that started with a ..

sloosecannon

I kinda thought that too... Maybe that was something weird from old Unix or something? (I already pendanted this guy once :P so didn't point it out)

ben_lubar

Additionally, unless rm -r deleted files from parent directories, it would only delete the parent of the current directory, not the whole system. Also, it would make wildcards pretty damn useless, so he's definitely talking out of his ass.

tar

@sloosecannon said:

I kinda thought that too... Maybe that was something weird from old Unix or something? (I already pendanted this guy once :P so didn't point it out)

There's some discussion of it on Stack Overflow, the current implement doesn't delete .* files unless it's specifically told to. I don't know whether that's a recent innovation or whether it's always been that way.

Will rm -rf * remove all files/folders in the current directory?

Will rm -rf * remove all files/folders in the current directory ? I want to make sure the wildcard * won't move up in upper directories and erase all my filesystem. :D I remember doing chmod 777 ....

accalia

@tar said:

it's always been that way

AFAICT it's a "bug" that's evolved to a feature over the years.

cvi

@tar said:

There's some discussion of it on Stack Overflow, the current implement doesn't delete .* files unless it's specifically told to.

@ben_lubar said:

Last time I checked, * didn't include any path that started with a ..

rm -rf * doesn't delete any hidden files (i.e., files starting with a .), because the shell doesn't include those files in the expansion of *. This is completely unrelated to rm and any implementations thereof.

However, additionally, rm refuses to remove . (the current directory) and .. (the parent directory) by default. But this is completely unrelated to the wildcard, it will refuse this even if you manually specify those folders on the command line:

$ rm -rf . ..
rm: cannot remove directory: ‘.’
rm: cannot remove directory: ‘..’

accalia

yes, also i can't be arsed to find if it's true or not so this may be urban legend here but....

I've always heard that the reason that . files are hidden is because there was a bug in the code that was supposed to stop * from expanding to include . and .. that only checked the first character so any directory entry that began with a dot was removed from teh expansion.... and everyone just kind of rolled with it.

no idea if it's true but it's a great story.

cvi

@accalia said:

no idea if it's true but it's a great story.

That could still be the reason to why shells don't expand * to include entries starting with . (hadn't heard that story before, but I wouldn't be surprised if it were true).

Nevertheless, that's still completely independent from rm. Plus, even if the wildcard would expand to include hidden directory entries including . and .., and the check I mentioned above didn't exist, any non-completely broken rm would only remove the parent directory and it's contents (and not the whole file system -- just as @ben_lubar mentioned), since rm -rf must filter .. when recursing directories. Otherwise rm -rf ./somedir would also empty the whole file system, thanks to recursing into ./somedir/.. etc.

flabdablet

@cartman82 said:

rm -rf ~

Doctor, it hurts when I do this!

ben_lubar

If you deleted your home, I think your problems are beyond what a doctor can help you with.

sloosecannon

Obviously. He can't even start his session without ~/.ssh/id_rsa

flabdablet

@tar said:

I have yet to find any discernible difference between Debian and Ubuntu

Killer differences for me:

Debian has a choice of release models: you can run Unstable, which is a rolling release; Stable, which is a periodical release with a high likelihood that Everything Just Works Together; or Testing, which tracks Unstable fairly closely except for a few months of being groomed as the next Stable.

My own Debian boxes are all set up to pull binary packages from Testing and source from Unstable, which means that
(a) most stuff Just Works straight off the repo
(b) if I need something newer than what's available in the Testing binaries repo, I can apt-get source --compile a package to get a built-for-me version from the Unstable source repo, install that with dpkg -i and forget about it, because it will eventually get superseded automatically as Testing rolls on.
Debian is a democracy; Canonical is a for-profit corporation. When my distro does something really astonishing and infuriating like adopting Gnome 3 or systemd without first having notified me via a courier in a horse-drawn carriage presenting a scroll on a silk cushion, I would much rather have that be the end result of publicly-accessible debate and discussion than the behind-closed-doors whim of an unaccountable CEO.

One of the main reasons I prefer free software, for all its faults, is that it avoids the constant upsell attempts associated with commercial software; years of experience as a software developer have left me somewhat allergic to the machinations of sales goons.

Onyx

@flabdablet said:

Gnome 3

I now have to derail this thread once again, but the latest stuff that got pulled from the repo (may have been there for a while, I was on Mint until recently where repos are behind)...

This is Nautilus, Gnome's file manager. I can no longer split the view into two panes. Also, these are default icon sizes. In details view!

This is Totem, Gnome's video player. Among other things, I can't find "Recently opened files" in it.

As a bonus, menus in Nautilus:

vs menus in Totem:

Discoursistency!

I honestly believe the whole Gnome team just went mad by this point. They have "everything's a webpage" brainworms. Hamburgers everywhere.

RaceProUK

Cinnamon

Onyx

I think I mentioned several times that I use Cinnamon. This is just stuff that got installed as dependencies in metapackages.

flabdablet

@Onyx said:

I honestly believe the whole Gnome team just went mad by this point.

Me too, which is why after getting fairly quickly past the Denial and Anger stages of grieving the loss of GNOME 2, I jumped ship to Xfce.

There are various things Xfce still does less well by default than GNOME 2 did, but it's been good enough for a good while. On the other hand, it's still got its hind leg trapped in the whole clusterfuck that is GTK.

LXQt looks like becoming the least-insane DE at some point fairly soon. Once it gains enough traction to land in a Debian-maintained repo I will probably switch to that.

Onyx

@flabdablet said:

grieving the loss of GNOME 2

MATE?

@flabdablet said:

LXQt looks like becoming the least-insane DE at some point fairly soon. Once it gains enough traction to land in a Debian-maintained repo I will probably switch to that.

I have to check that out again. My inner Qt fanboy demands it! :P

PleegWat

I actually like it from a UI approach. However, particularly for Nautilus, it is unacceptable from a feature loss standpoint.

I switched to an alternative file manager when I could not figure out a way to create a new sub directory when the list of files filled the entire list pane. There does not seem to be a button or menu option anywhere once right-clicking in an empty area was no longer possible.

flabdablet

@Onyx said:

MATE?

Didn't arrive fast enough, and once it did arrive it wasn't better than Xfce to an extent that made it worth switching back.

I also like the Xfce panel a whole lot more than the GNOME 2 one: xfce4-panel does layout via flexible-space panel elements rather than attempting to remember positions for things (the latter breaks horribly every time you connect a monitor with a different native resolution or change the DPI).

boomzilla

@tar said:

You know you can install Ubuntu Server, and it won't install any desktop packages? Then you can apt-get install kde4 once it finishes...

I didn't want to reinstall anything on this particular machine. I don't use it directly that much any more, so it's not that big of a deal.

Jaloopa

@TwelveBaud said:

Who the hell doesn't use Server Core?

People who are sensible enough to realise a GUI makes life easier?

anonymous234

Once again showing that the idea of getting all your software from a central server is incredibly stupid.

flabdablet

@cartman82 said:

There's NO excuse for not having a Trash can / Recycle bin like functionality on *nix after all these years.

Every desktop-like GUI that runs on Linux implements that functionality, which is also missing from the Windows CLIs; so this is really a GUI vs CLI thing than a *nix vs everything else thing.

That said, I like being able to use the CLI chainsaw without worrying about accidentally losing a leg. That's why I do all my Linux installs on top of LVM2 and keep at least one snapshot active for each partition.

If all you want is a chainguard on rm, you can get that with alias rm='rm -I' in your .bashrc.

TheCPUWizard

@Jaloopa said:

People who are sensible enough to realise a GUI makes life easier? (re: Server Core)

If you only have ONE server, then Core does not make too much sense. But if you have N servers with all but 1 (or 2 or 3) running Core, and the GUI used from another machine (the one not running core), you get tremendous advantages.

You do NOT give up having a GUI for 99% of the things (some DR is about it).

marinus

I distinctly remember, which must have been about 12 years ago, when I was still in middle school and experimenting, wanting to remove a directory's contents, and typing:

rm -rf *

This did not get rid of the dot-files, so I tried again:

rm -rf .* *

'Hmm, this is taking a long time... well, it's a big directory...'
'Hmm, this is taking a very long time...'

^C
# ls -a
ls: command not found

'Aw, fuck.'

# echo /*
/var /vmlinuz   (or something like that, it's long ago)

It had cheerfully "descended" into .. and eaten through pretty much everything. At least I learned this well before I was ever trusted with any responsibility.

(Edit: I just went and tried this in a VM, and at least for modern Debian I can confirm they actually have fixed this by now.)

ben_lubar

Ok, quick question:

Why did you have files you were editing one level below the root of the filesystem, anyway?

marinus

Because I was thirteen years old at the time.

[s](Besides, if it went up into .. it would've gone into ../.. too, so not like it matters.)[/s] I should learn to think before I type.

ben_lubar

No it wouldn't. * doesn't match slashes.

marinus

Hmm, yes, you're right. I had thought rm was at fault for descending into .. because of the -r option, but if that were the case, any rm -r would likely have triggered this, so it wasn't that, at least not by itself.

At least I had a reason for being root, I was trying to install something, but I don't remember what.

blakeyrat

On the other hand, Radar Men from the Moon is awesome.

blakeyrat

@TheCPUWizard said:

you get tremendous advantages.

Like what?

@TheCPUWizard said:

You do NOT give up having a GUI for 99% of the things (some DR is about it).

Right; but that's not what you're claiming. You're claiming you get a "tremendous advantage" by installing core. What advantage?

dkf

@sloosecannon said:

What's its current power level? Is it 400%?

You should have checked if it was OVER 9000!!!!