Is it a bug that zsh print the full string with printf '%.s'?
The command printf '%.0s-' `seq 1 30`; echo works fine in all shells tested:
/bin/jsh : ------------------------------
/bin/attsh : ------------------------------
/bin/y2sh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/lksh : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : ------------------------------
/bin/zsh4 : ------------------------------
Except for jsh (heirloom shell), y2sh Yet another shell, version 2.39 and lksh (Legacy Korn shell) all other implement a printf builtin:
/bin/attsh : printf is a shell builtin
/bin/ash : printf is a shell builtin
/bin/dash : printf is a shell builtin
/bin/b203sh : printf is a shell builtin
/bin/b43sh : printf is a shell builtin
/bin/b44sh : printf is a shell builtin
/bin/bash : printf is a shell builtin
/bin/ksh : printf is a shell builtin
/bin/ksh93 : printf is a shell builtin
/bin/mksh : printf is a shell builtin
/bin/zsh : printf is a shell builtin
/bin/zsh4 : printf is a shell builtin
But this line: printf '%.s-' `seq 1 30`; echo makes (only) zsh fail:
/bin/attsh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
/bin/zsh4 : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
The POSIX spec states that:
The precision shall take the form of a ( '.' ) followed by a decimal digit string; a null digit string is treated as zero.
Even if the s format specification states (in the same link):
If the precision is omitted from the argument, it shall be taken to be infinite, so all bytes up to the end of the string shall be written.
It could be reasonable argued that a "missing" precision digit is not "omitted" but has been set to a "null" and therefore should be interpreted as zero.
It would follow that zsh has a bug here.
Is that the correct explanation?
shell zsh printf
add a comment |
The command printf '%.0s-' `seq 1 30`; echo works fine in all shells tested:
/bin/jsh : ------------------------------
/bin/attsh : ------------------------------
/bin/y2sh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/lksh : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : ------------------------------
/bin/zsh4 : ------------------------------
Except for jsh (heirloom shell), y2sh Yet another shell, version 2.39 and lksh (Legacy Korn shell) all other implement a printf builtin:
/bin/attsh : printf is a shell builtin
/bin/ash : printf is a shell builtin
/bin/dash : printf is a shell builtin
/bin/b203sh : printf is a shell builtin
/bin/b43sh : printf is a shell builtin
/bin/b44sh : printf is a shell builtin
/bin/bash : printf is a shell builtin
/bin/ksh : printf is a shell builtin
/bin/ksh93 : printf is a shell builtin
/bin/mksh : printf is a shell builtin
/bin/zsh : printf is a shell builtin
/bin/zsh4 : printf is a shell builtin
But this line: printf '%.s-' `seq 1 30`; echo makes (only) zsh fail:
/bin/attsh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
/bin/zsh4 : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
The POSIX spec states that:
The precision shall take the form of a ( '.' ) followed by a decimal digit string; a null digit string is treated as zero.
Even if the s format specification states (in the same link):
If the precision is omitted from the argument, it shall be taken to be infinite, so all bytes up to the end of the string shall be written.
It could be reasonable argued that a "missing" precision digit is not "omitted" but has been set to a "null" and therefore should be interpreted as zero.
It would follow that zsh has a bug here.
Is that the correct explanation?
shell zsh printf
2
I'd say "bug". "Precision" refers to both the.and the optional digit string; an omitted precision looks like to%s, not%.s.
– chepner
Aug 11 '16 at 1:00
add a comment |
The command printf '%.0s-' `seq 1 30`; echo works fine in all shells tested:
/bin/jsh : ------------------------------
/bin/attsh : ------------------------------
/bin/y2sh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/lksh : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : ------------------------------
/bin/zsh4 : ------------------------------
Except for jsh (heirloom shell), y2sh Yet another shell, version 2.39 and lksh (Legacy Korn shell) all other implement a printf builtin:
/bin/attsh : printf is a shell builtin
/bin/ash : printf is a shell builtin
/bin/dash : printf is a shell builtin
/bin/b203sh : printf is a shell builtin
/bin/b43sh : printf is a shell builtin
/bin/b44sh : printf is a shell builtin
/bin/bash : printf is a shell builtin
/bin/ksh : printf is a shell builtin
/bin/ksh93 : printf is a shell builtin
/bin/mksh : printf is a shell builtin
/bin/zsh : printf is a shell builtin
/bin/zsh4 : printf is a shell builtin
But this line: printf '%.s-' `seq 1 30`; echo makes (only) zsh fail:
/bin/attsh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
/bin/zsh4 : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
The POSIX spec states that:
The precision shall take the form of a ( '.' ) followed by a decimal digit string; a null digit string is treated as zero.
Even if the s format specification states (in the same link):
If the precision is omitted from the argument, it shall be taken to be infinite, so all bytes up to the end of the string shall be written.
It could be reasonable argued that a "missing" precision digit is not "omitted" but has been set to a "null" and therefore should be interpreted as zero.
It would follow that zsh has a bug here.
Is that the correct explanation?
shell zsh printf
The command printf '%.0s-' `seq 1 30`; echo works fine in all shells tested:
/bin/jsh : ------------------------------
/bin/attsh : ------------------------------
/bin/y2sh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/lksh : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : ------------------------------
/bin/zsh4 : ------------------------------
Except for jsh (heirloom shell), y2sh Yet another shell, version 2.39 and lksh (Legacy Korn shell) all other implement a printf builtin:
/bin/attsh : printf is a shell builtin
/bin/ash : printf is a shell builtin
/bin/dash : printf is a shell builtin
/bin/b203sh : printf is a shell builtin
/bin/b43sh : printf is a shell builtin
/bin/b44sh : printf is a shell builtin
/bin/bash : printf is a shell builtin
/bin/ksh : printf is a shell builtin
/bin/ksh93 : printf is a shell builtin
/bin/mksh : printf is a shell builtin
/bin/zsh : printf is a shell builtin
/bin/zsh4 : printf is a shell builtin
But this line: printf '%.s-' `seq 1 30`; echo makes (only) zsh fail:
/bin/attsh : ------------------------------
/bin/ash : ------------------------------
/bin/dash : ------------------------------
/bin/b203sh : ------------------------------
/bin/b43sh : ------------------------------
/bin/b44sh : ------------------------------
/bin/bash : ------------------------------
/bin/ksh : ------------------------------
/bin/ksh93 : ------------------------------
/bin/mksh : ------------------------------
/bin/zsh : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
/bin/zsh4 : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-
The POSIX spec states that:
The precision shall take the form of a ( '.' ) followed by a decimal digit string; a null digit string is treated as zero.
Even if the s format specification states (in the same link):
If the precision is omitted from the argument, it shall be taken to be infinite, so all bytes up to the end of the string shall be written.
It could be reasonable argued that a "missing" precision digit is not "omitted" but has been set to a "null" and therefore should be interpreted as zero.
It would follow that zsh has a bug here.
Is that the correct explanation?
shell zsh printf
shell zsh printf
edited Aug 11 '16 at 3:45
asked Aug 11 '16 at 0:39
user79743
2
I'd say "bug". "Precision" refers to both the.and the optional digit string; an omitted precision looks like to%s, not%.s.
– chepner
Aug 11 '16 at 1:00
add a comment |
2
I'd say "bug". "Precision" refers to both the.and the optional digit string; an omitted precision looks like to%s, not%.s.
– chepner
Aug 11 '16 at 1:00
2
2
I'd say "bug". "Precision" refers to both the
. and the optional digit string; an omitted precision looks like to %s, not %.s.– chepner
Aug 11 '16 at 1:00
I'd say "bug". "Precision" refers to both the
. and the optional digit string; an omitted precision looks like to %s, not %.s.– chepner
Aug 11 '16 at 1:00
add a comment |
1 Answer
1
active
oldest
votes
Yes it is a bug (38306). The fix was released in Zsh 5.3.
Source: https://github.com/zsh-users/zsh/commit/e1c745a0dca56afb9cfcace1ef59449152290188
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
Great sleuthing; it's worth noting that the fix isn't in the officially released v5.2, however, so as of this writing the latest official release doesn't have the fix yet.
– mklement0
Aug 11 '16 at 18:45
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f302687%2fis-it-a-bug-that-zsh-print-the-full-string-with-printf-s%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes it is a bug (38306). The fix was released in Zsh 5.3.
Source: https://github.com/zsh-users/zsh/commit/e1c745a0dca56afb9cfcace1ef59449152290188
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
Great sleuthing; it's worth noting that the fix isn't in the officially released v5.2, however, so as of this writing the latest official release doesn't have the fix yet.
– mklement0
Aug 11 '16 at 18:45
add a comment |
Yes it is a bug (38306). The fix was released in Zsh 5.3.
Source: https://github.com/zsh-users/zsh/commit/e1c745a0dca56afb9cfcace1ef59449152290188
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
Great sleuthing; it's worth noting that the fix isn't in the officially released v5.2, however, so as of this writing the latest official release doesn't have the fix yet.
– mklement0
Aug 11 '16 at 18:45
add a comment |
Yes it is a bug (38306). The fix was released in Zsh 5.3.
Source: https://github.com/zsh-users/zsh/commit/e1c745a0dca56afb9cfcace1ef59449152290188
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
Yes it is a bug (38306). The fix was released in Zsh 5.3.
Source: https://github.com/zsh-users/zsh/commit/e1c745a0dca56afb9cfcace1ef59449152290188
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
edited 4 mins ago
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
answered Aug 11 '16 at 1:22
DarkHeartDarkHeart
3,52132340
3,52132340
Great sleuthing; it's worth noting that the fix isn't in the officially released v5.2, however, so as of this writing the latest official release doesn't have the fix yet.
– mklement0
Aug 11 '16 at 18:45
add a comment |
Great sleuthing; it's worth noting that the fix isn't in the officially released v5.2, however, so as of this writing the latest official release doesn't have the fix yet.
– mklement0
Aug 11 '16 at 18:45
Great sleuthing; it's worth noting that the fix isn't in the officially released v5.2, however, so as of this writing the latest official release doesn't have the fix yet.
– mklement0
Aug 11 '16 at 18:45
Great sleuthing; it's worth noting that the fix isn't in the officially released v5.2, however, so as of this writing the latest official release doesn't have the fix yet.
– mklement0
Aug 11 '16 at 18:45
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f302687%2fis-it-a-bug-that-zsh-print-the-full-string-with-printf-s%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I'd say "bug". "Precision" refers to both the
.and the optional digit string; an omitted precision looks like to%s, not%.s.– chepner
Aug 11 '16 at 1:00