Slightly confused about whether printf in the yash shell is a built-in command or not
The yash
shell has a printf
built-in, according to its manual.
However, this is what I see in a yash
shell with default configuration:
kk@eeyore ~ $ command -v printf
/usr/bin/printf
kk@eeyore ~ $ type printf
printf: a regular built-in at /usr/bin/printf
Is printf
a built-in in this shell or not? The result is similar for a number of other supposedly built-in utilities that are also available as external commands.
As a comparison, in pdksh
(ksh
on OpenBSD, where printf
is not a built-in):
$ command -v printf
/usr/bin/printf
$ type printf
printf is /usr/bin/printf
And in bash
(where printf
is a built-in):
$ command -v printf
printf
$ type printf
printf is a shell builtin
posix printf shell-builtin yash
add a comment |
The yash
shell has a printf
built-in, according to its manual.
However, this is what I see in a yash
shell with default configuration:
kk@eeyore ~ $ command -v printf
/usr/bin/printf
kk@eeyore ~ $ type printf
printf: a regular built-in at /usr/bin/printf
Is printf
a built-in in this shell or not? The result is similar for a number of other supposedly built-in utilities that are also available as external commands.
As a comparison, in pdksh
(ksh
on OpenBSD, where printf
is not a built-in):
$ command -v printf
/usr/bin/printf
$ type printf
printf is /usr/bin/printf
And in bash
(where printf
is a built-in):
$ command -v printf
printf
$ type printf
printf is a shell builtin
posix printf shell-builtin yash
1
It's a built-in -- a regular, not a special built-in. If you're confused about the difference between special and regular built-ins, or behavior mandated by the standard (see command search and execution 1.e.i.a) -- which requires that a binary should exist inPATH
in order for a regular built-in to be executed -- then please make your question about that.
– mosvy
2 hours ago
1
@mosvy This was a detail of the standard that was unknown to me. If you want to turn that into an answer, I'd be happy. I don't think I would need to update the question for this to be an appropriate answer, as I was unaware of this particular detail. Or I'll write it myself later.
– Kusalananda
2 hours ago
add a comment |
The yash
shell has a printf
built-in, according to its manual.
However, this is what I see in a yash
shell with default configuration:
kk@eeyore ~ $ command -v printf
/usr/bin/printf
kk@eeyore ~ $ type printf
printf: a regular built-in at /usr/bin/printf
Is printf
a built-in in this shell or not? The result is similar for a number of other supposedly built-in utilities that are also available as external commands.
As a comparison, in pdksh
(ksh
on OpenBSD, where printf
is not a built-in):
$ command -v printf
/usr/bin/printf
$ type printf
printf is /usr/bin/printf
And in bash
(where printf
is a built-in):
$ command -v printf
printf
$ type printf
printf is a shell builtin
posix printf shell-builtin yash
The yash
shell has a printf
built-in, according to its manual.
However, this is what I see in a yash
shell with default configuration:
kk@eeyore ~ $ command -v printf
/usr/bin/printf
kk@eeyore ~ $ type printf
printf: a regular built-in at /usr/bin/printf
Is printf
a built-in in this shell or not? The result is similar for a number of other supposedly built-in utilities that are also available as external commands.
As a comparison, in pdksh
(ksh
on OpenBSD, where printf
is not a built-in):
$ command -v printf
/usr/bin/printf
$ type printf
printf is /usr/bin/printf
And in bash
(where printf
is a built-in):
$ command -v printf
printf
$ type printf
printf is a shell builtin
posix printf shell-builtin yash
posix printf shell-builtin yash
edited 1 hour ago
Kusalananda
asked 3 hours ago
KusalanandaKusalananda
126k16239391
126k16239391
1
It's a built-in -- a regular, not a special built-in. If you're confused about the difference between special and regular built-ins, or behavior mandated by the standard (see command search and execution 1.e.i.a) -- which requires that a binary should exist inPATH
in order for a regular built-in to be executed -- then please make your question about that.
– mosvy
2 hours ago
1
@mosvy This was a detail of the standard that was unknown to me. If you want to turn that into an answer, I'd be happy. I don't think I would need to update the question for this to be an appropriate answer, as I was unaware of this particular detail. Or I'll write it myself later.
– Kusalananda
2 hours ago
add a comment |
1
It's a built-in -- a regular, not a special built-in. If you're confused about the difference between special and regular built-ins, or behavior mandated by the standard (see command search and execution 1.e.i.a) -- which requires that a binary should exist inPATH
in order for a regular built-in to be executed -- then please make your question about that.
– mosvy
2 hours ago
1
@mosvy This was a detail of the standard that was unknown to me. If you want to turn that into an answer, I'd be happy. I don't think I would need to update the question for this to be an appropriate answer, as I was unaware of this particular detail. Or I'll write it myself later.
– Kusalananda
2 hours ago
1
1
It's a built-in -- a regular, not a special built-in. If you're confused about the difference between special and regular built-ins, or behavior mandated by the standard (see command search and execution 1.e.i.a) -- which requires that a binary should exist in
PATH
in order for a regular built-in to be executed -- then please make your question about that.– mosvy
2 hours ago
It's a built-in -- a regular, not a special built-in. If you're confused about the difference between special and regular built-ins, or behavior mandated by the standard (see command search and execution 1.e.i.a) -- which requires that a binary should exist in
PATH
in order for a regular built-in to be executed -- then please make your question about that.– mosvy
2 hours ago
1
1
@mosvy This was a detail of the standard that was unknown to me. If you want to turn that into an answer, I'd be happy. I don't think I would need to update the question for this to be an appropriate answer, as I was unaware of this particular detail. Or I'll write it myself later.
– Kusalananda
2 hours ago
@mosvy This was a detail of the standard that was unknown to me. If you want to turn that into an answer, I'd be happy. I don't think I would need to update the question for this to be an appropriate answer, as I was unaware of this particular detail. Or I'll write it myself later.
– Kusalananda
2 hours ago
add a comment |
3 Answers
3
active
oldest
votes
The yash
shell does have, and does use, a built-in version of printf
(and other utilities). It just happens to be very pedantically POSIX compliant in the way it formulates the result of the command -v
and type
commands.
As mosvy comments, the POSIX standard requires that a regular built-in command be available as an external command for the built-in version of the command to be executed.
This is the relevant text from the standard:
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
If the command name does not contain any
<slash>
characters, the first successful step in the following sequence shall occur:
a. [...b, c, d... (these handle special built-ins, two sets of listed utilities (some of which
yash
refers to as "semi-special built-ins"), and shell functions]
e. Otherwise, the command shall be searched for using the
PATH
environment variable [...]
i. If the search is successful:
a. If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search. [...]
[...]
ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
This means that the output of command -v printf
signifies that the printf
command was found in the search path, while the output of type printf
adds to this that the command is a regular built-in.
Since the printf
command was found in the search path, and since it's a regular built-in in the shell, yash
will call its built-in version of the command. If the printf
was not found in the path, and if the yash
shell was running in POSIX-ly correct mode, an error would have been generated instead.
yash
prides itself on being a very POSIX compliant shell, and this is also true if we look at what POSIX says about command -v
:
-v
Write a string to standard output that indicates the pathname or command that will be used by the shell, in the current shell execution environment (see Shell Execution Environment), to invoke
command_name
, but do not invokecommand_name
.
- Utilities, regular built-in utilities,
command_names
including a<slash>
character, and any implementation-defined functions that are found using thePATH
variable (as described in Command Search and Execution), shall be written as absolute pathnames.
add a comment |
The Watanabe shell has three sorts of built-ins, described in detail in its manual. All of the built-in commands are also listed there, but one has to infer that something is a "regular" built-in command from the absence of any note saying that the command is a "special" or a "semi-special" built-in. Regular built-ins are unmarked.
printf
is one such "regular" built-in. In native mode it is always invoked, irrespective of whether there is an external command found by that name.
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in at /usr/bin/printf
$
$ PATH=/
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in (not found in $PATH)
$
But when the posixly-correct
shell option is set it is only a built-in if the external command can be found on the PATH
.
$ set --posixly-correct
$
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$
$ PATH=/
$ printf
yash: no such command `printf'
$
This is actually conformant to what the Single Unix Specifiation says, and has said since at least 1997.
It differs from the Z shell, the 93 Korn shell, the Bourne Again shell, and the Debian Almquist shell, none of which either implement or document such behaviour for regular built-ins. The Z shell, for example, documents that regular built-ins are always found, before the step that searches PATH
. So too does the Debian Almquist shell. And that's what these shells all do, even if invoked as sh
with their turn-on-POSIX options.
% /bin/exec -a sh zsh -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
zsh:printf:1: not enough arguments
% /bin/exec -a sh ksh93 -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
Usage: printf [ options ] format [string ...]
% /bin/exec -a sh bash --posix -c "PATH=/ type printf ; printf"
printf is a shell builtin
printf: usage: printf [-v var] format [arguments]
% /bin/exec -a sh dash -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
sh: 1: printf: usage: printf format [arg ...]
%
However, not running printf
when it is not on the PATH
is the behaviour of the PD Korn shell, the Heirloom Bourne shell, and the MirBSD Korn shell; because they do not have a printf
built-in in the first place. ☺
% /bin/exec -a sh `command -v ksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v oksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v jsh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh mksh -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% ksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% oksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% jsh -c "type printf ; printf"
printf is hashed (/usr/bin/printf)
usage: printf format [arguments ...]
% mksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
$
Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
– Kusalananda
52 mins ago
add a comment |
It seems to me like a yash mistake.
There are some built-ins that do not exist in the PATH (depending on the OS system):
a='dirs disown hash help history popd pushd suspend type typeset ulimit'
for b in $a; do type "$b"; done
Will print something like:
pushd: a regular built-in (not found in $PATH)
Which is a clear description: It is a builtin but there is no executable with the same name in the PATH.
However, this list (again, change with the OS system):
a='[ echo printf test'
for b in $a; do type "$b"; done
Will print lines like:
echo: a regular built-in at /bin/echo
Which, IMO, is a misleading description. Changing at
to also found in PATH at
:
echo: a regular built-in also found in PATH at /bin/echo
would be a better description.
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%2f496259%2fslightly-confused-about-whether-printf-in-the-yash-shell-is-a-built-in-command-o%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The yash
shell does have, and does use, a built-in version of printf
(and other utilities). It just happens to be very pedantically POSIX compliant in the way it formulates the result of the command -v
and type
commands.
As mosvy comments, the POSIX standard requires that a regular built-in command be available as an external command for the built-in version of the command to be executed.
This is the relevant text from the standard:
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
If the command name does not contain any
<slash>
characters, the first successful step in the following sequence shall occur:
a. [...b, c, d... (these handle special built-ins, two sets of listed utilities (some of which
yash
refers to as "semi-special built-ins"), and shell functions]
e. Otherwise, the command shall be searched for using the
PATH
environment variable [...]
i. If the search is successful:
a. If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search. [...]
[...]
ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
This means that the output of command -v printf
signifies that the printf
command was found in the search path, while the output of type printf
adds to this that the command is a regular built-in.
Since the printf
command was found in the search path, and since it's a regular built-in in the shell, yash
will call its built-in version of the command. If the printf
was not found in the path, and if the yash
shell was running in POSIX-ly correct mode, an error would have been generated instead.
yash
prides itself on being a very POSIX compliant shell, and this is also true if we look at what POSIX says about command -v
:
-v
Write a string to standard output that indicates the pathname or command that will be used by the shell, in the current shell execution environment (see Shell Execution Environment), to invoke
command_name
, but do not invokecommand_name
.
- Utilities, regular built-in utilities,
command_names
including a<slash>
character, and any implementation-defined functions that are found using thePATH
variable (as described in Command Search and Execution), shall be written as absolute pathnames.
add a comment |
The yash
shell does have, and does use, a built-in version of printf
(and other utilities). It just happens to be very pedantically POSIX compliant in the way it formulates the result of the command -v
and type
commands.
As mosvy comments, the POSIX standard requires that a regular built-in command be available as an external command for the built-in version of the command to be executed.
This is the relevant text from the standard:
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
If the command name does not contain any
<slash>
characters, the first successful step in the following sequence shall occur:
a. [...b, c, d... (these handle special built-ins, two sets of listed utilities (some of which
yash
refers to as "semi-special built-ins"), and shell functions]
e. Otherwise, the command shall be searched for using the
PATH
environment variable [...]
i. If the search is successful:
a. If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search. [...]
[...]
ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
This means that the output of command -v printf
signifies that the printf
command was found in the search path, while the output of type printf
adds to this that the command is a regular built-in.
Since the printf
command was found in the search path, and since it's a regular built-in in the shell, yash
will call its built-in version of the command. If the printf
was not found in the path, and if the yash
shell was running in POSIX-ly correct mode, an error would have been generated instead.
yash
prides itself on being a very POSIX compliant shell, and this is also true if we look at what POSIX says about command -v
:
-v
Write a string to standard output that indicates the pathname or command that will be used by the shell, in the current shell execution environment (see Shell Execution Environment), to invoke
command_name
, but do not invokecommand_name
.
- Utilities, regular built-in utilities,
command_names
including a<slash>
character, and any implementation-defined functions that are found using thePATH
variable (as described in Command Search and Execution), shall be written as absolute pathnames.
add a comment |
The yash
shell does have, and does use, a built-in version of printf
(and other utilities). It just happens to be very pedantically POSIX compliant in the way it formulates the result of the command -v
and type
commands.
As mosvy comments, the POSIX standard requires that a regular built-in command be available as an external command for the built-in version of the command to be executed.
This is the relevant text from the standard:
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
If the command name does not contain any
<slash>
characters, the first successful step in the following sequence shall occur:
a. [...b, c, d... (these handle special built-ins, two sets of listed utilities (some of which
yash
refers to as "semi-special built-ins"), and shell functions]
e. Otherwise, the command shall be searched for using the
PATH
environment variable [...]
i. If the search is successful:
a. If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search. [...]
[...]
ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
This means that the output of command -v printf
signifies that the printf
command was found in the search path, while the output of type printf
adds to this that the command is a regular built-in.
Since the printf
command was found in the search path, and since it's a regular built-in in the shell, yash
will call its built-in version of the command. If the printf
was not found in the path, and if the yash
shell was running in POSIX-ly correct mode, an error would have been generated instead.
yash
prides itself on being a very POSIX compliant shell, and this is also true if we look at what POSIX says about command -v
:
-v
Write a string to standard output that indicates the pathname or command that will be used by the shell, in the current shell execution environment (see Shell Execution Environment), to invoke
command_name
, but do not invokecommand_name
.
- Utilities, regular built-in utilities,
command_names
including a<slash>
character, and any implementation-defined functions that are found using thePATH
variable (as described in Command Search and Execution), shall be written as absolute pathnames.
The yash
shell does have, and does use, a built-in version of printf
(and other utilities). It just happens to be very pedantically POSIX compliant in the way it formulates the result of the command -v
and type
commands.
As mosvy comments, the POSIX standard requires that a regular built-in command be available as an external command for the built-in version of the command to be executed.
This is the relevant text from the standard:
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
If the command name does not contain any
<slash>
characters, the first successful step in the following sequence shall occur:
a. [...b, c, d... (these handle special built-ins, two sets of listed utilities (some of which
yash
refers to as "semi-special built-ins"), and shell functions]
e. Otherwise, the command shall be searched for using the
PATH
environment variable [...]
i. If the search is successful:
a. If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search. [...]
[...]
ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
This means that the output of command -v printf
signifies that the printf
command was found in the search path, while the output of type printf
adds to this that the command is a regular built-in.
Since the printf
command was found in the search path, and since it's a regular built-in in the shell, yash
will call its built-in version of the command. If the printf
was not found in the path, and if the yash
shell was running in POSIX-ly correct mode, an error would have been generated instead.
yash
prides itself on being a very POSIX compliant shell, and this is also true if we look at what POSIX says about command -v
:
-v
Write a string to standard output that indicates the pathname or command that will be used by the shell, in the current shell execution environment (see Shell Execution Environment), to invoke
command_name
, but do not invokecommand_name
.
- Utilities, regular built-in utilities,
command_names
including a<slash>
character, and any implementation-defined functions that are found using thePATH
variable (as described in Command Search and Execution), shall be written as absolute pathnames.
edited 6 mins ago
answered 1 hour ago
KusalanandaKusalananda
126k16239391
126k16239391
add a comment |
add a comment |
The Watanabe shell has three sorts of built-ins, described in detail in its manual. All of the built-in commands are also listed there, but one has to infer that something is a "regular" built-in command from the absence of any note saying that the command is a "special" or a "semi-special" built-in. Regular built-ins are unmarked.
printf
is one such "regular" built-in. In native mode it is always invoked, irrespective of whether there is an external command found by that name.
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in at /usr/bin/printf
$
$ PATH=/
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in (not found in $PATH)
$
But when the posixly-correct
shell option is set it is only a built-in if the external command can be found on the PATH
.
$ set --posixly-correct
$
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$
$ PATH=/
$ printf
yash: no such command `printf'
$
This is actually conformant to what the Single Unix Specifiation says, and has said since at least 1997.
It differs from the Z shell, the 93 Korn shell, the Bourne Again shell, and the Debian Almquist shell, none of which either implement or document such behaviour for regular built-ins. The Z shell, for example, documents that regular built-ins are always found, before the step that searches PATH
. So too does the Debian Almquist shell. And that's what these shells all do, even if invoked as sh
with their turn-on-POSIX options.
% /bin/exec -a sh zsh -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
zsh:printf:1: not enough arguments
% /bin/exec -a sh ksh93 -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
Usage: printf [ options ] format [string ...]
% /bin/exec -a sh bash --posix -c "PATH=/ type printf ; printf"
printf is a shell builtin
printf: usage: printf [-v var] format [arguments]
% /bin/exec -a sh dash -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
sh: 1: printf: usage: printf format [arg ...]
%
However, not running printf
when it is not on the PATH
is the behaviour of the PD Korn shell, the Heirloom Bourne shell, and the MirBSD Korn shell; because they do not have a printf
built-in in the first place. ☺
% /bin/exec -a sh `command -v ksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v oksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v jsh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh mksh -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% ksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% oksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% jsh -c "type printf ; printf"
printf is hashed (/usr/bin/printf)
usage: printf format [arguments ...]
% mksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
$
Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
– Kusalananda
52 mins ago
add a comment |
The Watanabe shell has three sorts of built-ins, described in detail in its manual. All of the built-in commands are also listed there, but one has to infer that something is a "regular" built-in command from the absence of any note saying that the command is a "special" or a "semi-special" built-in. Regular built-ins are unmarked.
printf
is one such "regular" built-in. In native mode it is always invoked, irrespective of whether there is an external command found by that name.
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in at /usr/bin/printf
$
$ PATH=/
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in (not found in $PATH)
$
But when the posixly-correct
shell option is set it is only a built-in if the external command can be found on the PATH
.
$ set --posixly-correct
$
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$
$ PATH=/
$ printf
yash: no such command `printf'
$
This is actually conformant to what the Single Unix Specifiation says, and has said since at least 1997.
It differs from the Z shell, the 93 Korn shell, the Bourne Again shell, and the Debian Almquist shell, none of which either implement or document such behaviour for regular built-ins. The Z shell, for example, documents that regular built-ins are always found, before the step that searches PATH
. So too does the Debian Almquist shell. And that's what these shells all do, even if invoked as sh
with their turn-on-POSIX options.
% /bin/exec -a sh zsh -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
zsh:printf:1: not enough arguments
% /bin/exec -a sh ksh93 -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
Usage: printf [ options ] format [string ...]
% /bin/exec -a sh bash --posix -c "PATH=/ type printf ; printf"
printf is a shell builtin
printf: usage: printf [-v var] format [arguments]
% /bin/exec -a sh dash -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
sh: 1: printf: usage: printf format [arg ...]
%
However, not running printf
when it is not on the PATH
is the behaviour of the PD Korn shell, the Heirloom Bourne shell, and the MirBSD Korn shell; because they do not have a printf
built-in in the first place. ☺
% /bin/exec -a sh `command -v ksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v oksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v jsh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh mksh -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% ksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% oksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% jsh -c "type printf ; printf"
printf is hashed (/usr/bin/printf)
usage: printf format [arguments ...]
% mksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
$
Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
– Kusalananda
52 mins ago
add a comment |
The Watanabe shell has three sorts of built-ins, described in detail in its manual. All of the built-in commands are also listed there, but one has to infer that something is a "regular" built-in command from the absence of any note saying that the command is a "special" or a "semi-special" built-in. Regular built-ins are unmarked.
printf
is one such "regular" built-in. In native mode it is always invoked, irrespective of whether there is an external command found by that name.
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in at /usr/bin/printf
$
$ PATH=/
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in (not found in $PATH)
$
But when the posixly-correct
shell option is set it is only a built-in if the external command can be found on the PATH
.
$ set --posixly-correct
$
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$
$ PATH=/
$ printf
yash: no such command `printf'
$
This is actually conformant to what the Single Unix Specifiation says, and has said since at least 1997.
It differs from the Z shell, the 93 Korn shell, the Bourne Again shell, and the Debian Almquist shell, none of which either implement or document such behaviour for regular built-ins. The Z shell, for example, documents that regular built-ins are always found, before the step that searches PATH
. So too does the Debian Almquist shell. And that's what these shells all do, even if invoked as sh
with their turn-on-POSIX options.
% /bin/exec -a sh zsh -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
zsh:printf:1: not enough arguments
% /bin/exec -a sh ksh93 -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
Usage: printf [ options ] format [string ...]
% /bin/exec -a sh bash --posix -c "PATH=/ type printf ; printf"
printf is a shell builtin
printf: usage: printf [-v var] format [arguments]
% /bin/exec -a sh dash -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
sh: 1: printf: usage: printf format [arg ...]
%
However, not running printf
when it is not on the PATH
is the behaviour of the PD Korn shell, the Heirloom Bourne shell, and the MirBSD Korn shell; because they do not have a printf
built-in in the first place. ☺
% /bin/exec -a sh `command -v ksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v oksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v jsh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh mksh -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% ksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% oksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% jsh -c "type printf ; printf"
printf is hashed (/usr/bin/printf)
usage: printf format [arguments ...]
% mksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
$
The Watanabe shell has three sorts of built-ins, described in detail in its manual. All of the built-in commands are also listed there, but one has to infer that something is a "regular" built-in command from the absence of any note saying that the command is a "special" or a "semi-special" built-in. Regular built-ins are unmarked.
printf
is one such "regular" built-in. In native mode it is always invoked, irrespective of whether there is an external command found by that name.
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in at /usr/bin/printf
$
$ PATH=/
$ printf
printf: this command requires an operand
$ type printf
printf: a regular built-in (not found in $PATH)
$
But when the posixly-correct
shell option is set it is only a built-in if the external command can be found on the PATH
.
$ set --posixly-correct
$
$ PATH=/usr/bin
$ printf
printf: this command requires an operand
$
$ PATH=/
$ printf
yash: no such command `printf'
$
This is actually conformant to what the Single Unix Specifiation says, and has said since at least 1997.
It differs from the Z shell, the 93 Korn shell, the Bourne Again shell, and the Debian Almquist shell, none of which either implement or document such behaviour for regular built-ins. The Z shell, for example, documents that regular built-ins are always found, before the step that searches PATH
. So too does the Debian Almquist shell. And that's what these shells all do, even if invoked as sh
with their turn-on-POSIX options.
% /bin/exec -a sh zsh -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
zsh:printf:1: not enough arguments
% /bin/exec -a sh ksh93 -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
Usage: printf [ options ] format [string ...]
% /bin/exec -a sh bash --posix -c "PATH=/ type printf ; printf"
printf is a shell builtin
printf: usage: printf [-v var] format [arguments]
% /bin/exec -a sh dash -c "PATH=/ ; type printf ; printf"
printf is a shell builtin
sh: 1: printf: usage: printf format [arg ...]
%
However, not running printf
when it is not on the PATH
is the behaviour of the PD Korn shell, the Heirloom Bourne shell, and the MirBSD Korn shell; because they do not have a printf
built-in in the first place. ☺
% /bin/exec -a sh `command -v ksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v oksh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh `command -v jsh` -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% /bin/exec -a sh mksh -c "PATH=/ ; type printf ; printf"
printf not found
sh: printf: not found
% ksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% oksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
% jsh -c "type printf ; printf"
printf is hashed (/usr/bin/printf)
usage: printf format [arguments ...]
% mksh -c "type printf ; printf"
printf is a tracked alias for /usr/bin/printf
usage: printf format [arguments ...]
$
answered 1 hour ago
JdeBPJdeBP
33.9k469159
33.9k469159
Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
– Kusalananda
52 mins ago
add a comment |
Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
– Kusalananda
52 mins ago
Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
– Kusalananda
52 mins ago
Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
– Kusalananda
52 mins ago
add a comment |
It seems to me like a yash mistake.
There are some built-ins that do not exist in the PATH (depending on the OS system):
a='dirs disown hash help history popd pushd suspend type typeset ulimit'
for b in $a; do type "$b"; done
Will print something like:
pushd: a regular built-in (not found in $PATH)
Which is a clear description: It is a builtin but there is no executable with the same name in the PATH.
However, this list (again, change with the OS system):
a='[ echo printf test'
for b in $a; do type "$b"; done
Will print lines like:
echo: a regular built-in at /bin/echo
Which, IMO, is a misleading description. Changing at
to also found in PATH at
:
echo: a regular built-in also found in PATH at /bin/echo
would be a better description.
add a comment |
It seems to me like a yash mistake.
There are some built-ins that do not exist in the PATH (depending on the OS system):
a='dirs disown hash help history popd pushd suspend type typeset ulimit'
for b in $a; do type "$b"; done
Will print something like:
pushd: a regular built-in (not found in $PATH)
Which is a clear description: It is a builtin but there is no executable with the same name in the PATH.
However, this list (again, change with the OS system):
a='[ echo printf test'
for b in $a; do type "$b"; done
Will print lines like:
echo: a regular built-in at /bin/echo
Which, IMO, is a misleading description. Changing at
to also found in PATH at
:
echo: a regular built-in also found in PATH at /bin/echo
would be a better description.
add a comment |
It seems to me like a yash mistake.
There are some built-ins that do not exist in the PATH (depending on the OS system):
a='dirs disown hash help history popd pushd suspend type typeset ulimit'
for b in $a; do type "$b"; done
Will print something like:
pushd: a regular built-in (not found in $PATH)
Which is a clear description: It is a builtin but there is no executable with the same name in the PATH.
However, this list (again, change with the OS system):
a='[ echo printf test'
for b in $a; do type "$b"; done
Will print lines like:
echo: a regular built-in at /bin/echo
Which, IMO, is a misleading description. Changing at
to also found in PATH at
:
echo: a regular built-in also found in PATH at /bin/echo
would be a better description.
It seems to me like a yash mistake.
There are some built-ins that do not exist in the PATH (depending on the OS system):
a='dirs disown hash help history popd pushd suspend type typeset ulimit'
for b in $a; do type "$b"; done
Will print something like:
pushd: a regular built-in (not found in $PATH)
Which is a clear description: It is a builtin but there is no executable with the same name in the PATH.
However, this list (again, change with the OS system):
a='[ echo printf test'
for b in $a; do type "$b"; done
Will print lines like:
echo: a regular built-in at /bin/echo
Which, IMO, is a misleading description. Changing at
to also found in PATH at
:
echo: a regular built-in also found in PATH at /bin/echo
would be a better description.
answered 29 mins ago
IsaacIsaac
11.6k11652
11.6k11652
add a comment |
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%2f496259%2fslightly-confused-about-whether-printf-in-the-yash-shell-is-a-built-in-command-o%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
1
It's a built-in -- a regular, not a special built-in. If you're confused about the difference between special and regular built-ins, or behavior mandated by the standard (see command search and execution 1.e.i.a) -- which requires that a binary should exist in
PATH
in order for a regular built-in to be executed -- then please make your question about that.– mosvy
2 hours ago
1
@mosvy This was a detail of the standard that was unknown to me. If you want to turn that into an answer, I'd be happy. I don't think I would need to update the question for this to be an appropriate answer, as I was unaware of this particular detail. Or I'll write it myself later.
– Kusalananda
2 hours ago