GNU bug report logs -
#47390
-i and -n options are order-sensitive
Previous Next
To reply to this bug, email your comments to 47390 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-sed <at> gnu.org
:
bug#47390
; Package
sed
.
(Thu, 25 Mar 2021 15:21:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rgrosso <r.grosso <at> gsi.de>
:
New bug report received and forwarded. Copy sent to
bug-sed <at> gnu.org
.
(Thu, 25 Mar 2021 15:21:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
To remove the first N lines from a big text file I used to do:
sed -in '1,Nd' bigfile.txt
and it was working as expected. Assuming the order of the flags does not
matter I did once:
sed -ni '1,Nd' bigfile.txt
which deleted the whole content of the file. Is this behaviour expected?
From the user point of view this seems like a rather dangerous bug. I
think, flags not taking an argument should be insensitive to the order.
Currently, to get the same result without running the risk to forget the
right order of the flags and deleting the file content, I do:
sed -i -e '1,Nd' bigfile.txt
(Using GNU sed 4.4 or 4.8)
Cheers,
Raffaele
Information forwarded
to
bug-sed <at> gnu.org
:
bug#47390
; Package
sed
.
(Wed, 28 Apr 2021 21:10:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 47390 <at> debbugs.gnu.org (full text, mbox):
Hello,
they are not order-sensitive, but the -i flag takes an optional argument (SUFFIX), therefore it cannot be grouped together with other short flags unless it is the last one.
> To remove the first N lines from a big text file I used to do:
>
> sed -in '1,Nd' bigfile.txt
>
> and it was working as expected.
In this invocation, the "n" is not a flag, it is the argument to the -i flag.
Same as:
sed --in-place=n '1,Nd' bigfile.txt
which tells sed to use "n" as the backup suffix (creating "bigfile.txtn" as backup of "bigfile.txt").
> Assuming the order of the flags does not matter I did once:
>
> sed -ni '1,Nd' bigfile.txt
>
> which deleted the whole content of the file. Is this behaviour expected?
In this invocation, you are passing both the -n and -i flags (the latter with no argument, which disables backup).
Same as:
sed --quiet --in-place '1,Nd' bigfile.txt
The output file will be empty as expected, because -n/--quiet disables automatic printing and you are not using any printing command in your sed script.
> From the user point of view this seems like a rather dangerous bug.
The -i flag of sed is well documented, and the docs include a warning for the very same pitfall you encountered:
https://www.gnu.org/software/sed/manual/sed.html#Command_002dLine-Options
You may think that flags with optional arguments are error prone (and I would agree), but there's nothing we can do about it here. GNU flags have worked like this for a long time.
> I think, flags not taking an argument should be insensitive to the order.
Usually they are, unless they are exclusive and the last one takes effect, but this is not the problem here.
> Currently, to get the same result without running the risk to forget the
> right order of the flags and deleting the file content, I do:
>
> sed -i -e '1,Nd' bigfile.txt
This has yet a different effect: the -i flag is without argument (no backup) and the -n is not present (autoprinting is on). The -e makes no difference in this case because there is only one script. If you want the "-in" effect, the only alternative is "--in-place=n".
Regards,
NP
Information forwarded
to
bug-sed <at> gnu.org
:
bug#47390
; Package
sed
.
(Thu, 29 Apr 2021 13:24:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 47390 <at> debbugs.gnu.org (full text, mbox):
Hello Nora,
thanks a lot for the explanations and sorry for the noise. Indeed, as
you said, the manual is clear about both pitfalls:
- that the '-i' should not be followed by any other short option in
general and
- that '-n' together with '-i' disables printing in the file so to say.
Thanks again for your time and for the extensive answer (I guess you
might have been tempted by a much shorter "RTFM" answer :-) )
Best regards, have a nice day,
Raffaele
On 4/28/21 11:09 PM, Nora Platiel wrote:
> Hello,
> they are not order-sensitive, but the -i flag takes an optional argument (SUFFIX), therefore it cannot be grouped together with other short flags unless it is the last one.
>
>> To remove the first N lines from a big text file I used to do:
>>
>> sed -in '1,Nd' bigfile.txt
>>
>> and it was working as expected.
> In this invocation, the "n" is not a flag, it is the argument to the -i
flag.
> Same as:
> sed --in-place=n '1,Nd' bigfile.txt
> which tells sed to use "n" as the backup suffix (creating "bigfile.txtn" as backup of "bigfile.txt").
>
>> Assuming the order of the flags does not matter I did once:
>>
>> sed -ni '1,Nd' bigfile.txt
>>
>> which deleted the whole content of the file. Is this behaviour expected?
> In this invocation, you are passing both the -n and -i flags (the latter with no argument, which disables backup).
> Same as:
> sed --quiet --in-place '1,Nd' bigfile.txt
> The output file will be empty as expected, because -n/--quiet disables automatic printing and you are not using any printing command in your sed
script.
>
>> From the user point of view this seems like a rather dangerous bug.
> The -i flag of sed is well documented, and the docs include a warning for the very same pitfall you encountered:
> https://www.gnu.org/software/sed/manual/sed.html#Command_002dLine-Options
> You may think that flags with optional arguments are error prone (and I
would agree), but there's nothing we can do about it here. GNU flags have
worked like this for a long time.
>
>> I think, flags not taking an argument should be insensitive to the order.
> Usually they are, unless they are exclusive and the last one takes effect, but this is not the problem here.
>
>> Currently, to get the same result without running the risk to forget the
>> right order of the flags and deleting the file content, I do:
>>
>> sed -i -e '1,Nd' bigfile.txt
> This has yet a different effect: the -i flag is without argument (no backup) and the -n is not present (autoprinting is on). The -e makes no difference in this case because there is only one script. If you want the "-in" effect, the only alternative is "--in-place=n".
>
> Regards,
> NP
>
This bug report was last modified 3 years and 191 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.