"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Omar Polo <op@omarpolo.com>
Subject:
Re: got: rm * removes current directory
To:
Stefan Sperling <stsp@stsp.name>
Cc:
Mikhail <mp39590@gmail.com>, gameoftrees@openbsd.org
Date:
Mon, 29 May 2023 10:51:47 +0200

Download raw body.

Thread
On 2023/05/29 10:15:00 +0200, Stefan Sperling <stsp@stsp.name> wrote:
> On Sun, May 28, 2023 at 08:33:20PM +0200, Omar Polo wrote:
> > On 2023/05/28 19:26:48 +0200, Stefan Sperling <stsp@stsp.name> wrote:
> > > On Sun, May 28, 2023 at 05:11:07PM +0200, Omar Polo wrote:
> > > > On 2023/05/28 12:59:39 +0200, Stefan Sperling <stsp@stsp.name> wrote:
> > > > Don't know, I'm not sure we should be using $PWD in lib/ to change the
> > > > behaviour, although removing $PWD is not nice.
> > > > 
> > > > Admittedly I haven't noticed the issue so far and won't consider it a
> > > > bad thing anyway, as it did what it is supposed to do.
> > > 
> > > Another point of concern is that the current behaviour of got rm
> > > contradicts the behaviour of /bin/rm.
> > > 
> > > /bin/rm does not allow the removal of "." or "..", and rm * will never
> > > result in the removal of "."
> > 
> > but even with this 'got rm' doesn't match rm.  It just adds a quirks
> > for the current working directory but otherwise keeps removing empty
> > ones, right?  I don't like quirks that much fwiw.
> 
> Yes, this is true. /bin/rm * will only remove files, not directories.
> 
> > rm and 'got rm' work on two different levels: one at the filesystem
> > level, where both files and directories are tracked, the other at the
> > "git view" of the filesystem, where only file exists and directories
> > are a byproduct.  I don't think there's much worth in trying to keep
> > these two tools behaving the same but if we want to, then 'got rm'
> > should keep directories around unless -R.
> > 
> > (do we need got rmdir too then? :P)

(got rmdir was meant to be a joke, didn't want to sound annoying)

> From my point of view this is a question of usabilty vs. design-purity.

Exactly!  I think in this case I'm more in the 'design-purity' camp,
but I can see the other point as well.

> [...]
> > I feel like the current behaviour is the one that sucks less.
> 
> I am happy to keep it as-is then. We can revisit this at any point
> if the issue ever gets raised again. I expect that people who work
> on the ports tree might run into this again eventually.

that was just an opinion, I was probably more loud than necessary;
apologize.

I won't feel bad if your diff gets committed, and the only real
comment I have on that is in the getcwd() usage in lib: I think it
would be better if code in lib/ doesn't change behaviour based on $PWD
(for foture-proofness.)

FWIW thanks to this discussion I discovered that find(1) -empty
matches empty directories as well so I have a workaround :)