Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Bug 210607] patch to bin/cat/cat.c to align output between when invoked with -be & -ne flags
7 views
Skip to first unread message
bugzilla...@freebsd.org
Jun 26, 2016, 9:49:02 PM6/26/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
Bug ID: 210607
Summary: patch to bin/cat/cat.c to align output between when
invoked with -be & -ne flags
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebs...@FreeBSD.org
Reporter: vent...@geeklan.co.uk
Created attachment 171845
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=171845&action=edit
patch cat.c & ATF tests
The attached patch amends bin/cat/cat.c so the output is the same aside
from blank lines being numbered or unnumbered, depending on whether cat
was invoked with -ne or -be.
At present, when cat is invoked with -be, there is an aditional
difference that the '$' on blank lines is placed on the far left of the
output.
The patch originates from r1.17 of bin/cat/cat.c from NetBSD.
Additionally, the ATF test is amended to test for the behaviour correctly (the
test previously only checked if text was aligned, without blank lines where the
issue being tested for was present). This change is present upstream but
provided here in case a vendor import is not feasible at this time.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs...@freebsd.org"
Bug ID: 210607
Summary: patch to bin/cat/cat.c to align output between when
invoked with -be & -ne flags
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: freebs...@FreeBSD.org
Reporter: vent...@geeklan.co.uk
Created attachment 171845
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=171845&action=edit
patch cat.c & ATF tests
The attached patch amends bin/cat/cat.c so the output is the same aside
from blank lines being numbered or unnumbered, depending on whether cat
was invoked with -ne or -be.
At present, when cat is invoked with -be, there is an aditional
difference that the '$' on blank lines is placed on the far left of the
output.
The patch originates from r1.17 of bin/cat/cat.c from NetBSD.
Additionally, the ATF test is amended to test for the behaviour correctly (the
test previously only checked if text was aligned, without blank lines where the
issue being tested for was present). This change is present upstream but
provided here in case a vendor import is not feasible at this time.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs...@freebsd.org"
bugzilla...@freebsd.org
Jul 1, 2016, 8:39:04 PM7/1/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
Mark Linimon <lin...@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
Mark Linimon <lin...@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
bugzilla...@freebsd.org
Aug 4, 2016, 12:59:48 PM8/4/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
John Baldwin <j...@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |j...@FreeBSD.org
--- Comment #1 from John Baldwin <j...@FreeBSD.org> ---
I actually find the current behavior the correct one. Note that GNU cat
follows the current behavior:
> gcat -ne
a b c
1 a b c$
2 $
def
3 def$
^D
vs:
> gcat -be
a b c
1 a b c$
$
def
2 def$
^D
The idea being that you only get leading indentation if there is a line number.
John Baldwin <j...@FreeBSD.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |j...@FreeBSD.org
--- Comment #1 from John Baldwin <j...@FreeBSD.org> ---
I actually find the current behavior the correct one. Note that GNU cat
follows the current behavior:
> gcat -ne
a b c
1 a b c$
2 $
def
3 def$
^D
vs:
> gcat -be
a b c
1 a b c$
$
def
2 def$
^D
The idea being that you only get leading indentation if there is a line number.
bugzilla...@freebsd.org
Aug 5, 2016, 10:15:12 AM8/5/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
--- Comment #2 from Sevan Janiyan <vent...@geeklan.co.uk> ---
(In reply to John Baldwin from comment #1)
> Note that GNU cat follows the current behavior:
These extensions to cat were introduced in BSD so the GNU implementation is an
imitation of ours
https://svnweb.freebsd.org/csrg/bin/cat/cat.c?r1=962&r2=1357
> The idea being that you only get leading indentation if there is a line number.
Going to the description in the man pages, there is no reference to such
behaviour which is really frustrating as it leaves it down to interpretation.
FreeBSD
-b "Number the non-blank output lines, starting at 1."
-e "Display non-printing characters (see the -v option), and display a dollar
sign (`$') at the end of each line."
-n "Number the output lines, starting at 1."
2.9.1BSD
-b "This, together with -n cause numbers to be omitted from blank lines."
-e "Follow ends of lines with the $ character."
-n "Number each line."
I'd say for consistency the output should the same aside from what gets omitted
with a specific flag when it is specified.
--- Comment #2 from Sevan Janiyan <vent...@geeklan.co.uk> ---
(In reply to John Baldwin from comment #1)
> Note that GNU cat follows the current behavior:
imitation of ours
https://svnweb.freebsd.org/csrg/bin/cat/cat.c?r1=962&r2=1357
> The idea being that you only get leading indentation if there is a line number.
behaviour which is really frustrating as it leaves it down to interpretation.
FreeBSD
-b "Number the non-blank output lines, starting at 1."
-e "Display non-printing characters (see the -v option), and display a dollar
sign (`$') at the end of each line."
-n "Number the output lines, starting at 1."
2.9.1BSD
-b "This, together with -n cause numbers to be omitted from blank lines."
-e "Follow ends of lines with the $ character."
-n "Number each line."
I'd say for consistency the output should the same aside from what gets omitted
with a specific flag when it is specified.
bugzilla...@freebsd.org
Aug 5, 2016, 11:29:04 AM8/5/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
--- Comment #3 from John Baldwin <j...@FreeBSD.org> ---
(In reply to Sevan Janiyan from comment #2)
1) The 'BSD' output from CSRG is the current one, not NetBSD's recent change.
The other output has been in place for 35 years. There has to be a compelling
reason to change it vs the tradeoff of breaking existing scripts and reducing
compatibility with other systems. 'cat' on OS X follows the current output as
well (inherited from BSD of course).
2) The language is not clear (and I'd be fine with clarifying it), but what you
are changing is to have 'cat -be' insert extra leading blankspace for blank
lines, but 'cat -b' does not. That seems far less intuitive to me from any of
the descriptions. It seems more consistent for 'cat -b' to always include
leading blankspace or to never include, not to only do it for '-e'.
--- Comment #3 from John Baldwin <j...@FreeBSD.org> ---
(In reply to Sevan Janiyan from comment #2)
1) The 'BSD' output from CSRG is the current one, not NetBSD's recent change.
The other output has been in place for 35 years. There has to be a compelling
reason to change it vs the tradeoff of breaking existing scripts and reducing
compatibility with other systems. 'cat' on OS X follows the current output as
well (inherited from BSD of course).
2) The language is not clear (and I'd be fine with clarifying it), but what you
are changing is to have 'cat -be' insert extra leading blankspace for blank
lines, but 'cat -b' does not. That seems far less intuitive to me from any of
the descriptions. It seems more consistent for 'cat -b' to always include
leading blankspace or to never include, not to only do it for '-e'.
bugzilla...@freebsd.org
Aug 5, 2016, 12:23:04 PM8/5/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
--- Comment #4 from Sevan Janiyan <vent...@geeklan.co.uk> ---
(In reply to John Baldwin from comment #3)
> 1) The 'BSD' output from CSRG is the current one, not NetBSD's recent change. The other output has been in place for 35 years.
That made me smile, <3
ok, the NetBSD change is nearly 10 years old. :)
> 2) The language is not clear (and I'd be fine with clarifying it), but what you are changing is to have 'cat -be' insert extra leading blankspace for blank lines, but 'cat -b' does not.
From the source code
/* -b implies -n */
/* -e implies -v */
Ignoring the -e flag & comparing the difference between -b & -n with the
following in a text file called a.txt
a b c
1 2 3
x y z
cat -b a.txt produces
1 a b c
2 1 2 3
3 x y z
cat -n a.txt produces
1 a b c
2
3 1 2 3
4
5 x y z
so if -b implies -n, when invoked with -e, would you build on that or give
another variant of output?
cat -be a.txt
$
3 x y z$
or
cat -be f.txt
$
3 x y z$
--- Comment #4 from Sevan Janiyan <vent...@geeklan.co.uk> ---
(In reply to John Baldwin from comment #3)
> 1) The 'BSD' output from CSRG is the current one, not NetBSD's recent change. The other output has been in place for 35 years.
ok, the NetBSD change is nearly 10 years old. :)
> 2) The language is not clear (and I'd be fine with clarifying it), but what you are changing is to have 'cat -be' insert extra leading blankspace for blank lines, but 'cat -b' does not.
/* -b implies -n */
/* -e implies -v */
Ignoring the -e flag & comparing the difference between -b & -n with the
following in a text file called a.txt
a b c
1 2 3
x y z
cat -b a.txt produces
1 a b c
2 1 2 3
3 x y z
cat -n a.txt produces
1 a b c
2
3 1 2 3
4
5 x y z
so if -b implies -n, when invoked with -e, would you build on that or give
another variant of output?
cat -be a.txt
1 a b c$
$
2 1 2 3$
$
$
3 x y z$
or
cat -be f.txt
1 a b c$
$
2 1 2 3$
$
$
3 x y z$
bugzilla...@freebsd.org
Aug 5, 2016, 1:30:29 PM8/5/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
--- Comment #5 from John Baldwin <j...@FreeBSD.org> ---
Pipe your non "-e" results through hd to see what I mean about -b not adding a
prefix. Right now, this will omit blank lines:
cat -b < foo | grep -v '^$'
because "plain" 'cat -b' doesn't modify the content of blank lines. Right now,
'cat -be' only modifies each line by adding the trailing '$', it does not
insert extra whitespace. The problem is that I think arguments can be made for
both interpretations, so I would err on the side of not changing things since
you risk breaking existing scripts/setups. I do think we should be more clear
in documenting.
--- Comment #5 from John Baldwin <j...@FreeBSD.org> ---
Pipe your non "-e" results through hd to see what I mean about -b not adding a
prefix. Right now, this will omit blank lines:
cat -b < foo | grep -v '^$'
because "plain" 'cat -b' doesn't modify the content of blank lines. Right now,
'cat -be' only modifies each line by adding the trailing '$', it does not
insert extra whitespace. The problem is that I think arguments can be made for
both interpretations, so I would err on the side of not changing things since
you risk breaking existing scripts/setups. I do think we should be more clear
in documenting.
bugzilla...@freebsd.org
Aug 5, 2016, 2:07:52 PM8/5/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
--- Comment #6 from Sevan Janiyan <vent...@geeklan.co.uk> ---
(In reply to John Baldwin from comment #5)
NetBSD, OpenBSD & DragonFlyBSD produces output one way & FreeBSD another. Just
as a heads up, the NetBSD test case for this behaviour did not exercise this
functionality (there weren't any blank lines in the test case) but just tested
that text was indented.
This has been corrected upstream in the NetBSD ATF tests so this issue may crop
up again should your contrib/netbsd-tests but updated to incorporate the new
test cases from NetBSD.
--- Comment #6 from Sevan Janiyan <vent...@geeklan.co.uk> ---
(In reply to John Baldwin from comment #5)
> The problem is that I think arguments can be made for both interpretations, so I would err on the side of not changing things since you risk breaking existing scripts/setups.
that's a shame but I respect your wishes, sadly this creates a new split where
NetBSD, OpenBSD & DragonFlyBSD produces output one way & FreeBSD another. Just
as a heads up, the NetBSD test case for this behaviour did not exercise this
functionality (there weren't any blank lines in the test case) but just tested
that text was indented.
This has been corrected upstream in the NetBSD ATF tests so this issue may crop
up again should your contrib/netbsd-tests but updated to incorporate the new
test cases from NetBSD.
bugzilla...@freebsd.org
Aug 5, 2016, 8:06:29 PM8/5/16
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210607
--- Comment #7 from John Baldwin <j...@FreeBSD.org> ---
My view isn't the only one, but I'm just very hesitant to change the existing
format. bdrewery@ prefers the newer format at least, so he might push this in
if you prod him enough.
--- Comment #7 from John Baldwin <j...@FreeBSD.org> ---
My view isn't the only one, but I'm just very hesitant to change the existing
format. bdrewery@ prefers the newer format at least, so he might push this in
if you prod him enough.
0 new messages