GNU bug report logs - #25540
notice issue in expand -- doesn't allow for expressing tabsize value in tabstop(s)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25540 in the body.
You can then email your comments to 25540 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: notice issue in expand -- doesn't allow for expressing tabsize value
 in tabstop(s)
Date: Wed, 25 Jan 2017 20:29:21 -0800

In programs that take tabstops, as an alternative to a tabsize, I've always
seen tabs beyond the end of the list taken as equal to the highest tab-stop
difference.  So for a tabsize=8, a tabset of 1,9 would be equivalent -- with
tabs above "9" being "9-1" or every 8th column above 9.

Otherwise you have no way of expression all tabs on a line that 
stretches out to
"???" 160? 240? what? other than to enumerate tabstops to infinity.

If they want to limit tabstops above the last to size "1", they can use 
something like 1,9,10.  How else can one specify tabs beyond the last
for a size other than "1"?

Could this be changed/fixed?

Message #8 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: Reuti <reuti <at> staff.uni-marburg.de>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Thu, 26 Jan 2017 11:26:40 +0100

[Message part 1 (text/plain, inline)]

> Am 26.01.2017 um 05:29 schrieb L A Walsh <coreutils <at> tlinx.org>:
> 
> 
> In programs that take tabstops, as an alternative to a tabsize, I've always
> seen tabs beyond the end of the list taken as equal to the highest tab-stop
> difference.  So for a tabsize=8, a tabset of 1,9 would be equivalent -- with
> tabs above "9" being "9-1" or every 8th column above 9.
> 
> Otherwise you have no way of expression all tabs on a line that stretches out to
> "???" 160? 240? what? other than to enumerate tabstops to infinity.
> 
> If they want to limit tabstops above the last to size "1", they can use something like 1,9,10.  How else can one specify tabs beyond the last
> for a size other than "1"?
> 
> Could this be changed/fixed?

For now the behavior is like specified on the info page: "[…] and replace any tabs beyond the last tab stop given with single spaces." To avoid that this gets broken, I would suggest to use a modified syntax like 1,9,30,34,/4 for using a width of 4 beyond 34.

This could even be expanded to: -t 2/4,120,4/5,/9

Two times a width of 4, a fixed 120, four times a width of 5 and all remaining have a width of 9 (could also be */9 instead of /9).

While we are on this:

expand -t 5,15,25,35 file
expand -t 5,15,25,,,,35 file

are AFAICS both the same. I would expect the second to behave different (using a space for the three tabs which have no value).

-- Reuti

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: L A Walsh <coreutils <at> tlinx.org>, 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Thu, 26 Jan 2017 10:29:00 +0000

On 26/01/17 04:29, L A Walsh wrote:
> 
> In programs that take tabstops, as an alternative to a tabsize, I've always
> seen tabs beyond the end of the list taken as equal to the highest tab-stop
> difference.  So for a tabsize=8, a tabset of 1,9 would be equivalent -- with
> tabs above "9" being "9-1" or every 8th column above 9.
> 
> Otherwise you have no way of expression all tabs on a line that 
> stretches out to
> "???" 160? 240? what? other than to enumerate tabstops to infinity.
> 
> If they want to limit tabstops above the last to size "1", they can use 
> something like 1,9,10.  How else can one specify tabs beyond the last
> for a size other than "1"?
> 
> Could this be changed/fixed?

This is a fair point:

  $ seq 8 | paste -s -d'\t' | expand --tabs=1,9
  1        2 3 4 5 6 7 8

Though changing that would break backwards compat,
and expand is documented in texinfo as doing exactly as above.
Moreover POSIX specifies exactly this operation:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/expand.html

So we'd have to use an extension to do this.
Perhaps something like:

  expand --tabs=1,9,...

cheers,
Pádraig

Message #14 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Reuti <reuti <at> staff.uni-marburg.de>, L A Walsh <coreutils <at> tlinx.org>
Cc: 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Thu, 26 Jan 2017 11:04:47 +0000

On 26/01/17 10:26, Reuti wrote:
> 
>> Am 26.01.2017 um 05:29 schrieb L A Walsh <coreutils <at> tlinx.org>:
>>
>>
>> In programs that take tabstops, as an alternative to a tabsize, I've always
>> seen tabs beyond the end of the list taken as equal to the highest tab-stop
>> difference.  So for a tabsize=8, a tabset of 1,9 would be equivalent -- with
>> tabs above "9" being "9-1" or every 8th column above 9.
>>
>> Otherwise you have no way of expression all tabs on a line that stretches out to
>> "???" 160? 240? what? other than to enumerate tabstops to infinity.
>>
>> If they want to limit tabstops above the last to size "1", they can use something like 1,9,10.  How else can one specify tabs beyond the last
>> for a size other than "1"?
>>
>> Could this be changed/fixed?
> 
> For now the behavior is like specified on the info page: "[…] and replace any tabs beyond the last tab stop given with single spaces." To avoid that this gets broken, I would suggest to use a modified syntax like 1,9,30,34,/4 for using a width of 4 beyond 34.
> 

I like that. Explicit and extensible.
An alternative could be: --tabs=1,9,30,34,+4 ?

> This could even be expanded to: -t 2/4,120,4/5,/9
> 
> Two times a width of 4, a fixed 120, four times a width of 5 and all remaining have a width of 9 (could also be */9 instead of /9).

That might be overkill.
It wouldn't provide extra functionality, only a shortcut,
and a very rarely used one at that.

> While we are on this:
> 
> expand -t 5,15,25,35 file
> expand -t 5,15,25,,,,35 file
> 
> are AFAICS both the same. I would expect the second to behave different (using a space for the three tabs which have no value).

I'm not sure we should assume empty = 1.
Note FreeBSD rejects this format:

  $ seq 8 | paste -s -d$'\t' - | expand -t1,,2
  expand: bad tab stop spec

One might consider and empty value after a comma to mean take the previous tab stop width,
and that would be a partially backwards compat way to provide the original request, i.e.:

  expand -t 1,9,,

However that seems a bit hacky and non obvious.

thanks,
Pádraig

Message #17 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: Reuti <reuti <at> staff.uni-marburg.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: L A Walsh <coreutils <at> tlinx.org>, 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Thu, 26 Jan 2017 12:27:27 +0100

[Message part 1 (text/plain, inline)]

> Am 26.01.2017 um 12:04 schrieb Pádraig Brady <P <at> draigBrady.com>:
> 
> On 26/01/17 10:26, Reuti wrote:
>> 
>>> Am 26.01.2017 um 05:29 schrieb L A Walsh <coreutils <at> tlinx.org>:
>>> 
>>> 
>>> In programs that take tabstops, as an alternative to a tabsize, I've always
>>> seen tabs beyond the end of the list taken as equal to the highest tab-stop
>>> difference.  So for a tabsize=8, a tabset of 1,9 would be equivalent -- with
>>> tabs above "9" being "9-1" or every 8th column above 9.
>>> 
>>> Otherwise you have no way of expression all tabs on a line that stretches out to
>>> "???" 160? 240? what? other than to enumerate tabstops to infinity.
>>> 
>>> If they want to limit tabstops above the last to size "1", they can use something like 1,9,10.  How else can one specify tabs beyond the last
>>> for a size other than "1"?
>>> 
>>> Could this be changed/fixed?
>> 
>> For now the behavior is like specified on the info page: "[…] and replace any tabs beyond the last tab stop given with single spaces." To avoid that this gets broken, I would suggest to use a modified syntax like 1,9,30,34,/4 for using a width of 4 beyond 34.
>> 
> 
> I like that. Explicit and extensible.
> An alternative could be: --tabs=1,9,30,34,+4 ?

Sure, this works too. In fact: I had this also in mind first, but with the extension to specify a multiplicator for the width I found "2+4" misleading and a slash more appropriate.

-- Reuti


> 
>> This could even be expanded to: -t 2/4,120,4/5,/9
>> 
>> Two times a width of 4, a fixed 120, four times a width of 5 and all remaining have a width of 9 (could also be */9 instead of /9).
> 
> That might be overkill.
> It wouldn't provide extra functionality, only a shortcut,
> and a very rarely used one at that.
> 
>> While we are on this:
>> 
>> expand -t 5,15,25,35 file
>> expand -t 5,15,25,,,,35 file
>> 
>> are AFAICS both the same. I would expect the second to behave different (using a space for the three tabs which have no value).
> 
> I'm not sure we should assume empty = 1.
> Note FreeBSD rejects this format:
> 
>  $ seq 8 | paste -s -d$'\t' - | expand -t1,,2
>  expand: bad tab stop spec
> 
> One might consider and empty value after a comma to mean take the previous tab stop width,
> and that would be a partially backwards compat way to provide the original request, i.e.:
> 
>  expand -t 1,9,,
> 
> However that seems a bit hacky and non obvious.
> 
> thanks,
> Pádraig

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Reuti <reuti <at> staff.uni-marburg.de>
Cc: 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Thu, 26 Jan 2017 04:53:31 -0800

Reuti wrote:

>  To avoid that this gets broken, I would suggest to use a modified syntax like 1,9,30,34,/4 for using a width of 4 beyond 34.
----
	It wouldn't be broken.  The syntax would become the same as on 
other platforms.  As it is now, it is already incompatible.  The point
is to make it consistent with other usages.

Message #23 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Reuti <reuti <at> staff.uni-marburg.de>
Cc: L A Walsh <coreutils <at> tlinx.org>, 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Sun, 26 Feb 2017 15:44:18 -0800

[Message part 1 (text/plain, inline)]

On 26/01/17 03:27, Reuti wrote:
> 
>> Am 26.01.2017 um 12:04 schrieb Pádraig Brady <P <at> draigBrady.com>:
>>
>> On 26/01/17 10:26, Reuti wrote:
>>>
>>>> Am 26.01.2017 um 05:29 schrieb L A Walsh <coreutils <at> tlinx.org>:
>>>>
>>>>
>>>> In programs that take tabstops, as an alternative to a tabsize, I've always
>>>> seen tabs beyond the end of the list taken as equal to the highest tab-stop
>>>> difference.  So for a tabsize=8, a tabset of 1,9 would be equivalent -- with
>>>> tabs above "9" being "9-1" or every 8th column above 9.
>>>>
>>>> Otherwise you have no way of expression all tabs on a line that stretches out to
>>>> "???" 160? 240? what? other than to enumerate tabstops to infinity.
>>>>
>>>> If they want to limit tabstops above the last to size "1", they can use something like 1,9,10.  How else can one specify tabs beyond the last
>>>> for a size other than "1"?
>>>>
>>>> Could this be changed/fixed?
>>>
>>> For now the behavior is like specified on the info page: "[…] and replace any tabs beyond the last tab stop given with single spaces." To avoid that this gets broken, I would suggest to use a modified syntax like 1,9,30,34,/4 for using a width of 4 beyond 34.
>>>
>>
>> I like that. Explicit and extensible.
>> An alternative could be: --tabs=1,9,30,34,+4 ?
> 
> Sure, this works too. In fact: I had this also in mind first, but with the extension to specify a multiplicator for the width I found "2+4" misleading and a slash more appropriate.
> 

Even without the multiplier a '+' would be misleading
since we wouldn't be necessarily adding that to the last value.

The attached uses your suggestion of '/' but only allowed in the last position.

thanks,
Pádraig.

[expand-trailing-tabsize.patch (text/x-patch, attachment)]

Message #26 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Reuti <reuti <at> staff.uni-marburg.de>
Cc: L A Walsh <coreutils <at> tlinx.org>, 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Tue, 28 Feb 2017 16:58:22 +0100

On 02/27/2017 12:44 AM, Pádraig Brady wrote:
> The attached uses your suggestion of '/' but only allowed in the last position.

Maybe it'd be good to have an example in the Texinfo manual as well.
Otherwise: LGTM, thanks!

Have a nice day,
Berny

Message #29 received at 25540 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 25540 <at> debbugs.gnu.org
Subject: Re: bug#25540: notice issue in expand -- doesn't allow for expressing
 tabsize value in tabstop(s)
Date: Sun, 28 Oct 2018 01:55:50 -0600

tags 25540 fixed
close 25540
stop


On 2017-02-28 8:58 a.m., Bernhard Voelker wrote:
> On 02/27/2017 12:44 AM, Pádraig Brady wrote:
>> The attached uses your suggestion of '/' but only allowed in the last position.
> 

Pushed here:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b1413b6011cd368fb4244f0aa79f4c4ea5ab50c5

Closing as "fixed".

-assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.