5.3: printf -

5.3: printf -

[Daniel Shahaf]

% printf -
printf: not enough arguments

Happens in sh mode too.  dash and bash [that's what I have handy] print
a minus sign.

Reported on IRC.

Re: 5.3: printf -

[Bart Schaefer]

On Dec 12, 11:41pm, Daniel Shahaf wrote:
}
} % printf -
} printf: not enough arguments
} 
} Happens in sh mode too.  dash and bash [that's what I have handy] print
} a minus sign.

I was going to blame this on zsh generally treating a single "-" like
"--" in argument lists (which is documented), but something is fishy:

torch% printf -- --      
printf: not enough arguments
torch% printf - -  
-%
torch% printf - --
printf: not enough arguments
torch% printf -- - 
-%
torch% printf -- -- --
--%

("%" there is PROMPT_SP of course).

Re: 5.3: printf -

[Daniel Shahaf]

Bart Schaefer wrote on Mon, Dec 12, 2016 at 20:21:10 -0800:
> On Dec 12, 11:41pm, Daniel Shahaf wrote:
> }
> } % printf -
> } printf: not enough arguments
> } 
> } Happens in sh mode too.  dash and bash [that's what I have handy] print
> } a minus sign.
> 
> I was going to blame this on zsh generally treating a single "-" like
> "--" in argument lists (which is documented), but something is fishy:
> 
> torch% printf -- --      
> printf: not enough arguments
> torch% printf - -  
> -%
> torch% printf - --
> printf: not enough arguments
> torch% printf -- - 
> -%
> torch% printf -- -- --
> --%

I think these should:

• In sh mode, emit argv[1] and ignore the others: it is the format
  string even if it happens to start with a minus.

• In zsh mode, interpret argv[1] as end-of-options, then emit argv[2]
  and ignore any other arguments: argv[2] is the format string.

Another case: «printf -x».

> ("%" there is PROMPT_SP of course).
> 

PATCH Re: 5.3: printf -

[Bart Schaefer]

Apparently this was introduced in 37467 when I changed "printf" from
having no options at all to having the -v option for print-to-variable.

There's some documentation saying that ideally we would not create any
new builtins with BINF_SKIPINVALID but I don't see any other way to get
back the old behavior.

diff --git a/Src/builtin.c b/Src/builtin.c
index 65e0cb1..0f04d14 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -100,7 +100,7 @@ static struct builtin builtins[] =
 
     BUILTIN("popd", BINF_SKIPINVALID | BINF_SKIPDASH | BINF_DASHDASHVALID, bin_cd, 0, 1, BIN_POPD, "q", NULL),
     BUILTIN("print", BINF_PRINTOPTS, bin_print, 0, -1, BIN_PRINT, "abcC:Df:ilmnNoOpPrRsSu:v:x:X:z-", NULL),
-    BUILTIN("printf", 0, bin_print, 1, -1, BIN_PRINTF, "v:", NULL),
+    BUILTIN("printf", BINF_SKIPINVALID | BINF_SKIPDASH, bin_print, 1, -1, BIN_PRINTF, "v:", NULL),
     BUILTIN("pushd", BINF_SKIPINVALID | BINF_SKIPDASH | BINF_DASHDASHVALID, bin_cd, 0, 2, BIN_PUSHD, "qsPL", NULL),
     BUILTIN("pushln", 0, bin_print, 0, -1, BIN_PRINT, NULL, "-nz"),
     BUILTIN("pwd", 0, bin_pwd, 0, 0, 0, "rLP", NULL),

Re: PATCH Re: 5.3: printf -

[Peter Stephenson]

On Tue, 13 Dec 2016 20:48:15 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Apparently this was introduced in 37467 when I changed "printf" from
> having no options at all to having the -v option for print-to-variable.
> 
> There's some documentation saying that ideally we would not create any
> new builtins with BINF_SKIPINVALID but I don't see any other way to get
> back the old behavior.

This was in any case ignoring the vagaries of traditional shell
behaviour, which demand inconsistency.  Supporting printf -v but
treating a - without a following alphanumeric as part of the string,
which seem to be the requirements we're faced with, aren't really
consistent.  So I think anything that works goes here.

pws

Re: PATCH Re: 5.3: printf -

[Daniel Shahaf]

Peter Stephenson wrote on Wed, Dec 14, 2016 at 09:39:22 +0000:
> On Tue, 13 Dec 2016 20:48:15 -0800
> Bart Schaefer <schaefer@brasslantern.com> wrote:
> > Apparently this was introduced in 37467 when I changed "printf" from
> > having no options at all to having the -v option for print-to-variable.
> > 
> > There's some documentation saying that ideally we would not create any
> > new builtins with BINF_SKIPINVALID but I don't see any other way to get
> > back the old behavior.
> 
> This was in any case ignoring the vagaries of traditional shell
> behaviour, which demand inconsistency.  Supporting printf -v but
> treating a - without a following alphanumeric as part of the string,
> which seem to be the requirements we're faced with, aren't really
> consistent.  So I think anything that works goes here.

The grandparent patch fixes all the cases given so far in this thread,
except that «printf --» and «printf -- -» yield an error and "-",
respectively — whereas in sh mode they should both print "--".

I'd tried to split the printf logic out of bin_print() [lines 4648
through end of function] in order to pave the way for a separate
bin_printf(), but with little success.

Thanks,

Daniel

Re: PATCH Re: 5.3: printf -

[Bart Schaefer]

On Dec 14,  4:51pm, Daniel Shahaf wrote:
}
} The grandparent patch fixes all the cases given so far in this thread,
} except that "printf --" and "printf -- -" yield an error and "-",
} respectively - whereas in sh mode they should both print "--".

Bash prints an error and "-" respectively in those two cases as well,
so I think it's unclear what should happen for that in sh mode.

$ printf --
printf: usage: printf [-v var] format [arguments]

Re: PATCH Re: 5.3: printf -

[Daniel Shahaf]

Bart Schaefer wrote on Wed, Dec 14, 2016 at 10:44:50 -0800:
> On Dec 14,  4:51pm, Daniel Shahaf wrote:
> }
> } The grandparent patch fixes all the cases given so far in this thread,
> } except that "printf --" and "printf -- -" yield an error and "-",
> } respectively - whereas in sh mode they should both print "--".
> 
> Bash prints an error and "-" respectively in those two cases as well,
> so I think it's unclear what should happen for that in sh mode.

I was aiming for POSIX-compliance, not bash-compliance, for sh mode.

Re: PATCH Re: 5.3: printf -

[Chet Ramey]

On 12/14/16 7:50 PM, Daniel Shahaf wrote:
> Bart Schaefer wrote on Wed, Dec 14, 2016 at 10:44:50 -0800:
>> On Dec 14,  4:51pm, Daniel Shahaf wrote:
>> }
>> } The grandparent patch fixes all the cases given so far in this thread,
>> } except that "printf --" and "printf -- -" yield an error and "-",
>> } respectively - whereas in sh mode they should both print "--".
>>
>> Bash prints an error and "-" respectively in those two cases as well,
>> so I think it's unclear what should happen for that in sh mode.
> 
> I was aiming for POSIX-compliance, not bash-compliance, for sh mode.

The format is not optional, according to Posix.  All shells aiming for
Posix conformance throw an error on `printf --'.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Re: PATCH Re: 5.3: printf -

[Daniel Shahaf]

Chet Ramey wrote on Wed, Dec 14, 2016 at 20:14:31 -0500:
> On 12/14/16 7:50 PM, Daniel Shahaf wrote:
> > Bart Schaefer wrote on Wed, Dec 14, 2016 at 10:44:50 -0800:
> >> On Dec 14,  4:51pm, Daniel Shahaf wrote:
> >> }
> >> } The grandparent patch fixes all the cases given so far in this thread,
> >> } except that "printf --" and "printf -- -" yield an error and "-",
> >> } respectively - whereas in sh mode they should both print "--".
> >>
> >> Bash prints an error and "-" respectively in those two cases as well,
> >> so I think it's unclear what should happen for that in sh mode.
> > 
> > I was aiming for POSIX-compliance, not bash-compliance, for sh mode.
> 
> The format is not optional, according to Posix.

Sure.

> All shells aiming for Posix conformance throw an error on `printf --'.

This surprises me; it doesn't match my understanding of the spec.
(I thought POSIX would take "--" to be the format string.)

Cheers,

Daniel
(trying not to repeat myself _too_ much..)

Re: PATCH Re: 5.3: printf -

[Chet Ramey]

On 12/15/16 5:45 PM, Daniel Shahaf wrote:

> This surprises me; it doesn't match my understanding of the spec.
> (I thought POSIX would take "--" to be the format string.)

"Standard utilities that do not accept options, but that do accept
operands, shall recognize "--" as a first argument to be discarded."

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Re: PATCH Re: 5.3: printf -

[Daniel Shahaf]

Chet Ramey wrote on Thu, Dec 15, 2016 at 18:48:13 -0500:
> On 12/15/16 5:45 PM, Daniel Shahaf wrote:
> 
> > This surprises me; it doesn't match my understanding of the spec.
> > (I thought POSIX would take "--" to be the format string.)
> 
> "Standard utilities that do not accept options, but that do accept
> operands, shall recognize "--" as a first argument to be discarded."
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04

Thank you for the reference.

diff --git a/Test/B03print.ztst b/Test/B03print.ztst
index 7a43f9c..c65568a 100644
--- a/Test/B03print.ztst
+++ b/Test/B03print.ztst
@@ -334,5 +334,3 @@
 0:regression test of printf with assorted ambiguous options or formats
 >------x
 ?(eval):printf:3: not enough arguments
-F:There is some question whether "printf --" should be an error as above,
-F:or should treat "--" as the format string.  Bash agrees on the error.