tag 64326 notabug
close 64326
stop
On 6/28/23 19:33, Chris Elvidge wrote:
> On 28/06/2023 16:41, Arsen Arsenović via GNU coreutils Bug Reports wrote:
>> Hi,
>>
>> LitHack writes:
>>
>>> Basically what it doing is that it doesn't recognise (-) this as a file
>>> name part even when using (\-). Th
Or rm -- -abc
The "double-dash" signals "end of options"
On 28/06/2023 16:41, Arsen Arsenović via GNU coreutils Bug Reports wrote:
Hi,
LitHack writes:
Basically what it doing is that it doesn't recognise (-) this as a file
name part even when using (\-). This bug will work on most of utilit
Hi,
LitHack writes:
> Basically what it doing is that it doesn't recognise (-) this as a file
> name part even when using (\-). This bug will work on most of utilities
> like cat, cp etc
This is simply how argument parsing and shell syntax work. 'rm \-abc'
is equivalent to just 'rm -abc', whic
Basically what it doing is that it doesn't recognise (-) this as a file
name part even when using (\-). This bug will work on most of utilities
like cat, cp etc
Thanks and regards
All I can say is wow! You guys are either really good or really bored
:-) Maybe both!
Thanks for all of the comments, suggestions and discussion. A lot of
people around here use ksh or bash. It would probably be worthwhile
making the switch--not specifically for this, but for all of the ot
According to Jon Stanley on 1/26/2010 7:05 PM:
> On Tue, Jan 26, 2010 at 8:57 PM, Michael Webb wrote:
>
>> I'm running /bin/csh. Don't know how to figure out the coreutil version,
>> however the rm man-page says 5.2.1.
Wow, that's old. The latest stable version is 8.4, and includes several
fix
Jon Stanley wrote:
> Yeah, like Eric said, I think that this is a csh problem rather than a
> coreutils problem. I would even think that csh is behaving wrongly
> here - rather than refusing to run rm because the glob didn't match,
> it should pass the f* straight through to rm to deal with as it
>
Jon Stanley writes:
>
> Yeah, like Eric said, I think that this is a csh problem rather than a
> coreutils problem. I would even think that csh is behaving wrongly
> here - rather than refusing to run rm because the glob didn't match,
> it should pass the f* straight through to rm to deal with as
On Tue, Jan 26, 2010 at 8:57 PM, Michael Webb wrote:
> I'm running /bin/csh. Don't know how to figure out the coreutil version,
> however the rm man-page says 5.2.1.
Yeah, like Eric said, I think that this is a csh problem rather than a
coreutils problem. I would even think that csh is behaving
According to Michael Webb on 1/26/2010 6:19 PM:
> Hello,
>
> This is just a nit I discovered, but I thought I'd pass it along.
>
> I am within a directory containing directories dir1 and dir2 and *no*
> files starting with f.
>
> shell> rm -rf dir1 dir2 f*
> rm: No match.
Which version of
On Tue, Jan 26, 2010 at 8:19 PM, Michael Webb wrote:
> I suspect the "No match" is coming from the command line parsing and not rm
> itself. However, the message starts with rm.
I would suspect you're right - I just tried on my Fedora 12 system
(coreuitls 7.6, which is not the current release)
Michael Webb writes:
>
> I am within a directory containing directories dir1 and dir2 and *no*
> files starting with f.
>
>shell> rm -rf dir1 dir2 f*
>rm: No match.
[...]
> I suspect the "No match" is coming from the command line parsing and not
> rm itself. However, the message start
Hello,
This is just a nit I discovered, but I thought I'd pass it along.
I am within a directory containing directories dir1 and dir2 and *no*
files starting with f.
shell> rm -rf dir1 dir2 f*
rm: No match.
From the man page:
-f, --force
ignore nonexistent files, never pr
James Youngman wrote:
> While I think about it, it might also be worth enhancing
> the --help output to point out that "rm ./*" is safe while "rm *"
> might do things you did not expect (think "touch ./-rf").
It just seems so scary putting in a suggestion "rm ./*". Also I might
debate as to the
Hmm, well, I'm not sure I'd put "rm ./*" in the --help output.
It'd be a bit like giving a sharp knife to a 7-year-old, no?
Also, "rm ./*" doesn't remove the dot files.
Perhaps we should just let sleeping dogs lie.
___
Bug-coreutils mailing list
Bug-cor
On Mon, Aug 29, 2005 at 02:17:10PM -0700, Paul Eggert wrote:
> The latter, but this comes up so often (I must have seen this reported
> a hundred times...) that I thought I'd try to improve the diagnostic.
> I installed this:
>
> 2005-08-29 Paul Eggert <[EMAIL PROTECTED]>
>
> * NEWS: "rm
[EMAIL PROTECTED] writes:
> I cannot remove files which beggins with "-"
> for example:
> -TRY_TO_REMOVE_THIS_FILE
> is this bug, or I don't know how to use "rm"?
The latter, but this comes up so often (I must have seen this reported
a hundred times...) that I thought I'd try to improve the diagn
[EMAIL PROTECTED] wrote:
> I cannot remove files which beggins with "-"
> for example:
> -TRY_TO_REMOVE_THIS_FILE
> is this bug, or I don't know how to use "rm"?
If you run:
rm --help
Or:
man rm
You will see the following text which describes your problem.
To remove a file whose name
I cannot remove files which beggins with "-"
for example:
-TRY_TO_REMOVE_THIS_FILE
is this bug, or I don't know how to use "rm"?
:-)
bye
Goran
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Roman Avdeenko wrote:
> Run command
> rm -f *
> in virusmails directory
> And see
> -bash: /bin/rm: Argument list too long
A common misunderstanding. The answer to your question is documented
here:
http://www.gnu.org/software/coreutils/faq/
Look for "Argument list too long".
In very short su
Hi!
I use RH90.
Run command
rm -f *
in virusmails directory
And see
-bash: /bin/rm: Argument list too long
Type
ls -la
drwxrwxrwt2 root root 48 Jan 31 15:02 tmp
drwxr-xr-x2 amavis amavis2347376 Feb 2 12:00 virusmails
drwxr-xr-x4 root root 128 Dec 21 21:
"Aldo Elam" <[EMAIL PROTECTED]> writes:
>
> dear coreutils programmers,
>
> I have recently found a disturbing fact about the command "rm". I tried
> to delete a directory, all files in the directory was erased but two
> files:
>
> ls -l
> total 8
> -rwxr-xr-x1 root root 31
I have recently found a disturbing fact about the command "rm". I
tried to delete a directory, all files in the directory was erased
but two files:
ls -l
total 8
-rwxr-xr-x1 root root 319 Jan 18 23:24 -fn=0&si=135296
-rwxr-xr-x1 root root 319
dear coreutils programmers,
I have recently found a disturbing fact about the command "rm". I tried
to delete a directory, all files in the directory was erased but two
files:
ls -l
total 8
-rwxr-xr-x1 root root 319 Jan 18 23:24 -fn=0&si=135296
-rwxr-xr-x1 root root
Hi,
I apologize for not sending the full error report;
what I get is the following (on a machine running
RedHat 9.0, not some prehistoric system):
$ \rm a b*
rm: No match.
$ \rm -f a b*
rm: No match.
OK, I got the right answer when I switched to "bash";
the wrong answer occurs in "tcsh", which
there seems to be a weird bug with the "rm" command, at least
with "rm (coreutils) 4.5.3".
This is an quite old version of, the latest stable is 5.0.
Just try the following commands,
rm -i a b*
rm -f a b*
in a test directory containing a file named "a" and
Hi,
there seems to be a weird bug with the "rm"
command, at least with "rm (coreutils) 4.5.3".
Just try the following commands,
rm -i a b*
rm -f a b*
in a test directory containing a file named "a"
and no file with a name starting with "b".
Best wishes,
Paulo Nogueira
_
rm test failed for coreutils-5.0
I was building coreutils-5.0 on a Solaris 8 box using gcc.
./configue
make
make check
There was an error in make check for the directory rm when run as
root. Here is an abbreviated version version.
he2un76:/tmp/coreutils-5.0/tests/rm:># make check
28 matches
Mail list logo
