bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/04/2012 06:55 PM, Linda A. Walsh wrote: So how do delete all files in the directory without wild cards? Why tie your hands behind your back? Use wild cards: cd DIRECTORY rm -fr * .[!.] .??* If you do this a lot, put it into a shell script. It's not like the need is all that common, for most people, but if you need it that's what scripts are for. If you fiddle with your shell settings about how wildcards are expanded, make sure your script does wildcards in the standard way.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/05/2012 08:25 AM, Paul Eggert wrote: On 09/04/2012 06:55 PM, Linda A. Walsh wrote: So how do delete all files in the directory without wild cards? Why tie your hands behind your back? Use wild cards: cd DIRECTORY rm -fr * .[!.] .??* If you do this a lot, put it into a shell script. It's not like the need is all that common, for most people, but if you need it that's what scripts are for. If you fiddle with your shell settings about how wildcards are expanded, make sure your script does wildcards in the standard way. Exactly, we're now at the point where globbing is the topic, much way away from coreutils and rm. Bash knows dotglob: $ mkdir d; cd d $ touch .a b ; mkdir c $ ( shopt -s dotglob ; rm -rv * ) removed `.a' removed `b' removed directory: `c' Have a nice day, Berny
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/04/2012 11:58 PM, Linda A. Walsh wrote: I'm not talking for interactive use... I'm talking for use in a script that might run on systems that are not mine -- so I can't rely on shell settings. Yes you can. Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/04/2012 11:58 PM, Linda A. Walsh wrote: I'm not talking for interactive use... I'm talking for use in a script that might run on systems that are not mine -- so I can't rely on shell settings. Yes you can. Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area. To what level of posix... if they are compliant to the original level then they might have the original behavior that allowed rm -r . to work. if they are the 2003 version, then a different way, .. bleh. I overly worry about things that don't occur, but get caught by things I didn't worry enough about. So it doesn't really matter. I just preferred simplicity to the ever changing posix.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/05/2012 07:51 AM, Linda A. Walsh wrote: Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area. To what level of posix... To all the levels that are relevant for this discussion. In practice, people use #!/bin/sh and it works pretty well to avoid compatibility issues like this. It's not perfect for all POSIX issues, but you were asking for a solution to a particular problem, and this should solve your problem.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/05/2012 07:51 AM, Linda A. Walsh wrote: Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area. To what level of posix... To all the levels that are relevant for this discussion. In practice, people use #!/bin/sh and it works pretty well to avoid compatibility issues like this. It's not perfect for all POSIX issues, but you were asking for a solution to a particular problem, and this should solve your problem. - Now I remember how I got here in the first place... It was because of bash moving to the POSIX 2003 standard and breaking many things I'd come to rely on, that I eventually realized that it was unsuitable to rely on for programming. I had written a logical volume snapshot generator and manager in about ~1500 lines of shell script across multiple files -- mostly as a proof of concept -- but also because it seemed simple and grew as I realized it was 90% error condition handling. Bash got very unreliable in handling error conditions via -e w/the new POSIX standard -- can't return non zero from a function (so no more mathematical functions), can't return non-zero from a calc (()) or let statement -- both of which now trigger error exits under -e due to POSIX More stuff happened, I decided to throw it away and rewrite in perl. I'm still wanting to call rm -fr without wild cards to remove everything in a directory. One would think the rm utility which is *designed* to remove files recursively, would do the task and NOT need the shell to do it's job. My perl program has tried to call rm -fr . and *, neither of which work. if rm can't remove all the files in a dir by itself -- I assert it is failing it's job as an 'rm' program. Removing files is it's sole job in life... it can remove singles and directories... using rm -fr ./. or dir/. or . were all ways of removing all contents under their targets without removing the directory. That feature is now gone. So I'd like to request it be added when not operating under POSIX_CORRECTLY. It's the right thing to do for the command line. We don't have so many clueless dweebs in a tty window -- most want point and click. I know I don't want to call bash as a helper for rm -- as I know with BASH_ENV, and such, it can very easily be running alot of overhead code besides the simple rm function I wanted to do. I think on many systems /bin/sh is a link to ash or dash, and no telling how they will act/perform -- I don't want an extra dependency. So should I start looking to write a patch for rm and possibly fork it? Just realizing that I'm where I'm at today because of bash going POSIX has left me pretty cold.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Jim Meyering wrote: These commands would evoke an invalid diagnostic: $ mkdir d ln -s d s env rm -r s/ rm: cannot remove 's': Too many levels of symbolic links remove.c was stripping trailing slashes from s/ before passing the name to rm. But a trailing slash may change the semantics, and thus should not be stripped. I would assert that the trailing . shouldn't be stripped either. If the directory is a mount point -- then . would indicate the contents of the mount point -- being after the /, while the / would be the mount point itself. In my case, I wanted to delete everything in the mount point. Removal of the mount point itself would ideally unmount the 'fs', but I won't hold my breath on that one (and leave the root inode of the file system in the unmounted file system -- thus I've effectively removed . from mountpoint/. Which is different from the . of a directory entry -- NO I'm not asking for this as a feature, I'm just saying it would be a valid semantic paradigm). I WOULD want rm dir foobar/. to remove all contents in the directory before failing on .. The original version of posix didn't have this restriction/problem. POSIX is portability standard -- it should not be regarded as a restrictive standard, unless not doing so would hinder portability. In effect, they are disallowing OS's to make extensions beyond what they allow in the newer standards... That goes WAY beyond a portability standard...
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/04/2012 11:46 AM, Linda A. Walsh wrote: POSIX is portability standard -- it should not be regarded as a restrictive standard, unless not doing so would hinder portability. In effect, they are disallowing OS's to make extensions beyond what they allow in the newer standards... That's where you are wrong. POSIX _does_ allow OS's to make extensions beyond the standard. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/04/2012 10:46 AM, Linda A. Walsh wrote: I would assert that the trailing . shouldn't be stripped either. If we were designing anew, I'd be inclined to agree with you. But there are probably people expecting the standard behavior now, i.e. expecting it to do nothing useful other than issue an error? Who would type that in, expecting that? What useful purpose does it serve? and there's an argument for not departing from the standard unless there's a good reason. Usability, Expressiveness. Here, if we can provide a command rm -fr foo/ to do what you want, then I hope it's merely a minor glitch that rm -fr foo/. Ok, will foo/ remove the contents only and not the directory? If so, then it's a replacement -- that sounds like what is being talked about .. yes? It seems so fragile -- because some utils require the /. to make sure you don't ALSO remove the directory. if I remove foo/. I know, unambigously, that the directory foo won't be removed. With foo/, it will depend on the program. That means other programs will have to change to be compat with the new standard -- when they were all compat before when foo/. did a recursive remove and gave an error at the end about can't remove . That was a behavior I've relied on...(i.e. if it really did remove ., that would defeat the purpose of the of the safety invocation. However, adding foo/ -- does that imply that ./ will also work? so now rm -fr ./ will work? That's awfully close to rm -fr /. just as rm -fr ./* is close to rm -fr /.* I've never relied on rm to protect me from rm -fr /, which is why I have tended to use relative paths with . and ending in . if I wanted to keep the dir, or not -- as there is ALOT of code out there that removes trailing slashes... (like the code under discussion -- perfect example)it is by far not the only one to treat '/' as option at the end of a path.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/04/2012 04:21 PM, Linda A. Walsh wrote: Paul Eggert wrote: expecting it to do nothing useful other than issue an error? Sure. People might expect the utility to complain about what they consider to be obvious typos, rather than to remove files they don't expect to be removed. For example: rm -fr .* safely removes all file names beginning with . in the working directory, without inadvertently removing file names that do not begin with ., or files in the parent directory. I can see people being used to this sort of thing, and being annoyed greatly if we change it. Ok, will foo/ remove the contents only and not the directory? No, rm -fr foo/ removes the directory too. It seems so fragile -- because some utils require the /. to make sure you don't ALSO remove the directory. Which utilities are those? The standard POSIX style is that foo/ names the directory. However, adding foo/ -- does that imply that ./ will also work? No, ./ is treated as .. Sorry.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/04/2012 04:21 PM, Linda A. Walsh wrote: Paul Eggert wrote: expecting it to do nothing useful other than issue an error? Sure. People might expect the utility to complain about what they consider to be obvious typos, rather than to remove files they don't expect to be removed. For example: rm -fr .* safely removes all file names beginning with . in the working directory, without inadvertently removing file names that do not begin with ., or files in the parent directory. I can see people being used to this sort of thing, and being annoyed greatly if we change it. i wouldn't regard that as safe. I always use rm -fr .[^.]* Why is that interfaces must sync to the lowest level. unix was NOT supposed to be that way. Ok, will foo/ remove the contents only and not the directory? No, rm -fr foo/ removes the directory too. So how do delete all files in the directory without wild cards? (as you don't know how or if they will be expanded). (only VERY recently has bash included . in * -- it used to be ignored and still is if you have flags set to ignore it. Shells don't consistently expand wildcards, and the OS doesn't expand them at all (i.e. when passed in 'exec')... This is what I mean about useful features being removed in order to dumb down the interface -- as dir/ also tries to remove the dir... which isn't likely to work on a mount point.
