Slightly confused about whether printf in the yash shell is a built-in command or not

13

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

share|improve this question

edited Jan 23 at 18:51

Kusalananda

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

• 
  
  
  

  
  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
  Jan 23 at 17:30
  

  
  
  
  


• 
  
  
  

  
  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
  Jan 23 at 17:37
  
  
  

  
  
  
  

add a comment | 

13

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

share|improve this question

edited Jan 23 at 18:51

Kusalananda

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

• 
  
  
  

  
  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
  Jan 23 at 17:30
  

  
  
  
  


• 
  
  
  

  
  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
  Jan 23 at 17:37
  
  
  

  
  
  
  

add a comment | 

13

13

13

1

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

share|improve this question

edited Jan 23 at 18:51

Kusalananda

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

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

share|improve this question

edited Jan 23 at 18:51

Kusalananda

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

share|improve this question

edited Jan 23 at 18:51

Kusalananda

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

share|improve this question

share|improve this question

edited Jan 23 at 18:51

Kusalananda

edited Jan 23 at 18:51

Kusalananda

edited Jan 23 at 18:51

Kusalananda

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

asked Jan 23 at 16:38

KusalanandaKusalananda

135k17255422

135k17255422

• 
  
  
  

  
  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
  Jan 23 at 17:30
  

  
  
  
  


• 
  
  
  

  
  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
  Jan 23 at 17:37
  
  
  

  
  
  
  

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 in PATH in order for a regular built-in to be executed -- then please make your question about that.
  
  – mosvy
  Jan 23 at 17:30
  

  
  
  
  


• 
  
  
  

  
  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
  Jan 23 at 17:37
  
  
  

  
  
  
  

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
Jan 23 at 17:30

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
Jan 23 at 17:30

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
Jan 23 at 17:37

@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
Jan 23 at 17:37

add a comment | 

3 Answers
3

active

oldest

votes

13

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 in $PATH for the built-in version of the command to be executed.

This is the relevant text from the standard:

Command Search and Execution

If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:

1. 
   

   If the command name does not contain any <slash> characters, the first successful step in the following sequence shall occur:

   
   
   
   
   
   • 
     

     a. If the command name matches the name of a special built-in utility, that special built-in utility shall be invoked.

     
     
     

     [...]

     
     
   
   
   • e. Otherwise, the command shall be searched for using the PATH environment variable as described in XBD Environment Variables :
     
     
     
     
     • 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.
         
       
       
       • b. Otherwise, the shell executes the utility in a separate utility environment [...]
         
         [...]
       
       
       
       
     
     
     • ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
     
     
     
     
   
   
   
   


2. If the command name contains at least one <slash>, [...]

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 invoke command_name.

• Utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-defined functions that are found using the PATH variable (as described in Command Search and Execution), shall be written as absolute pathnames.

share|improve this answer

edited Jan 24 at 7:29

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  Does anyone know why POSIX has this requirement for an external command to exist before running the built-in command?
  
  – studog
  Jan 23 at 21:14
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @studog You may want to ask that as a separate new question, possibly referring to this answer and/or question.
  
  – Kusalananda
  Jan 23 at 21:49
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Done: unix.stackexchange.com/questions/496341/…
  
  – studog
  Jan 23 at 22:28
  

  
  
  
  

add a comment | 

6

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 ...]

$

share|improve this answer

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
  
  – Kusalananda
  Jan 23 at 19:03
  
  
  

  
  
  
  

add a comment | 

-1

The wording could be improved.

If the shell is in posix mode: set --posixly-correct:

For regular built-ins that do not exist in the PATH this is printed:

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, for regular built-ins which name also exist in the PATH, this is printed:

echo: a regular built-in at /bin/echo

Which, seems to imply that the executable at /bin/echo will be executed (which will not be). I suggest that a change from at to also found in PATH at:

echo: a regular built-in also found in PATH at /bin/echo

would make a better description. Maybe enclosing that in parenthesis (as the other answer did) could make it better.

---

In POSIX mode, no regular builtin will work unless it is also found in the PATH.

However, both (POSIX) special:

break colon continue dot eval exec exit export

readonly return set shift times trap unset

And yash's semi-special (not special for POSIX):

alias bg cd command false fc fg getopts jobs

kill pwd read true umask unalias wait

builtins still work.

share|improve this answer

edited Jan 25 at 2:05

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

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
});


}
});

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.

draft saved

draft discarded

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

Name

Email

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

Name

Email

Required, but never shown

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

active

oldest

votes

active

oldest

votes

13

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 in $PATH for the built-in version of the command to be executed.

This is the relevant text from the standard:

Command Search and Execution

If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:

1. 
   

   If the command name does not contain any <slash> characters, the first successful step in the following sequence shall occur:

   
   
   
   
   
   • 
     

     a. If the command name matches the name of a special built-in utility, that special built-in utility shall be invoked.

     
     
     

     [...]

     
     
   
   
   • e. Otherwise, the command shall be searched for using the PATH environment variable as described in XBD Environment Variables :
     
     
     
     
     • 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.
         
       
       
       • b. Otherwise, the shell executes the utility in a separate utility environment [...]
         
         [...]
       
       
       
       
     
     
     • ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
     
     
     
     
   
   
   
   


2. If the command name contains at least one <slash>, [...]

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 invoke command_name.

• Utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-defined functions that are found using the PATH variable (as described in Command Search and Execution), shall be written as absolute pathnames.

share|improve this answer

edited Jan 24 at 7:29

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  Does anyone know why POSIX has this requirement for an external command to exist before running the built-in command?
  
  – studog
  Jan 23 at 21:14
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @studog You may want to ask that as a separate new question, possibly referring to this answer and/or question.
  
  – Kusalananda
  Jan 23 at 21:49
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Done: unix.stackexchange.com/questions/496341/…
  
  – studog
  Jan 23 at 22:28
  

  
  
  
  

add a comment | 

13

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 in $PATH for the built-in version of the command to be executed.

This is the relevant text from the standard:

Command Search and Execution

If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:

1. 
   

   If the command name does not contain any <slash> characters, the first successful step in the following sequence shall occur:

   
   
   
   
   
   • 
     

     a. If the command name matches the name of a special built-in utility, that special built-in utility shall be invoked.

     
     
     

     [...]

     
     
   
   
   • e. Otherwise, the command shall be searched for using the PATH environment variable as described in XBD Environment Variables :
     
     
     
     
     • 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.
         
       
       
       • b. Otherwise, the shell executes the utility in a separate utility environment [...]
         
         [...]
       
       
       
       
     
     
     • ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
     
     
     
     
   
   
   
   


2. If the command name contains at least one <slash>, [...]

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 invoke command_name.

• Utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-defined functions that are found using the PATH variable (as described in Command Search and Execution), shall be written as absolute pathnames.

share|improve this answer

edited Jan 24 at 7:29

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  Does anyone know why POSIX has this requirement for an external command to exist before running the built-in command?
  
  – studog
  Jan 23 at 21:14
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @studog You may want to ask that as a separate new question, possibly referring to this answer and/or question.
  
  – Kusalananda
  Jan 23 at 21:49
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Done: unix.stackexchange.com/questions/496341/…
  
  – studog
  Jan 23 at 22:28
  

  
  
  
  

add a comment | 

13

13

13

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 in $PATH for the built-in version of the command to be executed.

This is the relevant text from the standard:

Command Search and Execution

If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:

1. 
   

   If the command name does not contain any <slash> characters, the first successful step in the following sequence shall occur:

   
   
   
   
   
   • 
     

     a. If the command name matches the name of a special built-in utility, that special built-in utility shall be invoked.

     
     
     

     [...]

     
     
   
   
   • e. Otherwise, the command shall be searched for using the PATH environment variable as described in XBD Environment Variables :
     
     
     
     
     • 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.
         
       
       
       • b. Otherwise, the shell executes the utility in a separate utility environment [...]
         
         [...]
       
       
       
       
     
     
     • ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
     
     
     
     
   
   
   
   


2. If the command name contains at least one <slash>, [...]

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 invoke command_name.

• Utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-defined functions that are found using the PATH variable (as described in Command Search and Execution), shall be written as absolute pathnames.

share|improve this answer

edited Jan 24 at 7:29

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

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 in $PATH for the built-in version of the command to be executed.

This is the relevant text from the standard:

Command Search and Execution

If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:

1. 
   

   If the command name does not contain any <slash> characters, the first successful step in the following sequence shall occur:

   
   
   
   
   
   • 
     

     a. If the command name matches the name of a special built-in utility, that special built-in utility shall be invoked.

     
     
     

     [...]

     
     
   
   
   • e. Otherwise, the command shall be searched for using the PATH environment variable as described in XBD Environment Variables :
     
     
     
     
     • 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.
         
       
       
       • b. Otherwise, the shell executes the utility in a separate utility environment [...]
         
         [...]
       
       
       
       
     
     
     • ii. If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
     
     
     
     
   
   
   
   


2. If the command name contains at least one <slash>, [...]

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 invoke command_name.

• Utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-defined functions that are found using the PATH variable (as described in Command Search and Execution), shall be written as absolute pathnames.

share|improve this answer

edited Jan 24 at 7:29

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

share|improve this answer

share|improve this answer

edited Jan 24 at 7:29

edited Jan 24 at 7:29

edited Jan 24 at 7:29

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

answered Jan 23 at 18:46

KusalanandaKusalananda

135k17255422

135k17255422

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  Does anyone know why POSIX has this requirement for an external command to exist before running the built-in command?
  
  – studog
  Jan 23 at 21:14
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @studog You may want to ask that as a separate new question, possibly referring to this answer and/or question.
  
  – Kusalananda
  Jan 23 at 21:49
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Done: unix.stackexchange.com/questions/496341/…
  
  – studog
  Jan 23 at 22:28
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  Does anyone know why POSIX has this requirement for an external command to exist before running the built-in command?
  
  – studog
  Jan 23 at 21:14
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @studog You may want to ask that as a separate new question, possibly referring to this answer and/or question.
  
  – Kusalananda
  Jan 23 at 21:49
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Done: unix.stackexchange.com/questions/496341/…
  
  – studog
  Jan 23 at 22:28
  

  
  
  
  

3

3

Does anyone know why POSIX has this requirement for an external command to exist before running the built-in command?

– studog
Jan 23 at 21:14

Does anyone know why POSIX has this requirement for an external command to exist before running the built-in command?

– studog
Jan 23 at 21:14

@studog You may want to ask that as a separate new question, possibly referring to this answer and/or question.

– Kusalananda
Jan 23 at 21:49

@studog You may want to ask that as a separate new question, possibly referring to this answer and/or question.

– Kusalananda
Jan 23 at 21:49

1

1

Done: unix.stackexchange.com/questions/496341/…

– studog
Jan 23 at 22:28

Done: unix.stackexchange.com/questions/496341/…

– studog
Jan 23 at 22:28

add a comment | 

6

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 ...]

$

share|improve this answer

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
  
  – Kusalananda
  Jan 23 at 19:03
  
  
  

  
  
  
  

add a comment | 

6

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 ...]

$

share|improve this answer

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
  
  – Kusalananda
  Jan 23 at 19:03
  
  
  

  
  
  
  

add a comment | 

6

6

6

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 ...]

$

share|improve this answer

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

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 ...]

$

share|improve this answer

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

share|improve this answer

share|improve this answer

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

answered Jan 23 at 18:55

JdeBPJdeBP

36.5k473174

36.5k473174

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
  
  – Kusalananda
  Jan 23 at 19:03
  
  
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.
  
  – Kusalananda
  Jan 23 at 19:03
  
  
  

  
  
  
  

Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.

– Kusalananda
Jan 23 at 19:03

Good! Thanks for confirming and for adding the shell-specific bits to my knowledge! I like this shell more already.

– Kusalananda
Jan 23 at 19:03

add a comment | 

-1

The wording could be improved.

If the shell is in posix mode: set --posixly-correct:

For regular built-ins that do not exist in the PATH this is printed:

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, for regular built-ins which name also exist in the PATH, this is printed:

echo: a regular built-in at /bin/echo

Which, seems to imply that the executable at /bin/echo will be executed (which will not be). I suggest that a change from at to also found in PATH at:

echo: a regular built-in also found in PATH at /bin/echo

would make a better description. Maybe enclosing that in parenthesis (as the other answer did) could make it better.

---

In POSIX mode, no regular builtin will work unless it is also found in the PATH.

However, both (POSIX) special:

break colon continue dot eval exec exit export

readonly return set shift times trap unset

And yash's semi-special (not special for POSIX):

alias bg cd command false fc fg getopts jobs

kill pwd read true umask unalias wait

builtins still work.

share|improve this answer

edited Jan 25 at 2:05

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

add a comment | 

-1

The wording could be improved.

If the shell is in posix mode: set --posixly-correct:

For regular built-ins that do not exist in the PATH this is printed:

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, for regular built-ins which name also exist in the PATH, this is printed:

echo: a regular built-in at /bin/echo

Which, seems to imply that the executable at /bin/echo will be executed (which will not be). I suggest that a change from at to also found in PATH at:

echo: a regular built-in also found in PATH at /bin/echo

would make a better description. Maybe enclosing that in parenthesis (as the other answer did) could make it better.

---

In POSIX mode, no regular builtin will work unless it is also found in the PATH.

However, both (POSIX) special:

break colon continue dot eval exec exit export

readonly return set shift times trap unset

And yash's semi-special (not special for POSIX):

alias bg cd command false fc fg getopts jobs

kill pwd read true umask unalias wait

builtins still work.

share|improve this answer

edited Jan 25 at 2:05

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

add a comment | 

-1

-1

-1

The wording could be improved.

If the shell is in posix mode: set --posixly-correct:

For regular built-ins that do not exist in the PATH this is printed:

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, for regular built-ins which name also exist in the PATH, this is printed:

echo: a regular built-in at /bin/echo

Which, seems to imply that the executable at /bin/echo will be executed (which will not be). I suggest that a change from at to also found in PATH at:

echo: a regular built-in also found in PATH at /bin/echo

would make a better description. Maybe enclosing that in parenthesis (as the other answer did) could make it better.

---

In POSIX mode, no regular builtin will work unless it is also found in the PATH.

However, both (POSIX) special:

break colon continue dot eval exec exit export

readonly return set shift times trap unset

And yash's semi-special (not special for POSIX):

alias bg cd command false fc fg getopts jobs

kill pwd read true umask unalias wait

builtins still work.

share|improve this answer

edited Jan 25 at 2:05

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

The wording could be improved.

If the shell is in posix mode: set --posixly-correct:

For regular built-ins that do not exist in the PATH this is printed:

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, for regular built-ins which name also exist in the PATH, this is printed:

echo: a regular built-in at /bin/echo

Which, seems to imply that the executable at /bin/echo will be executed (which will not be). I suggest that a change from at to also found in PATH at:

echo: a regular built-in also found in PATH at /bin/echo

would make a better description. Maybe enclosing that in parenthesis (as the other answer did) could make it better.

---

In POSIX mode, no regular builtin will work unless it is also found in the PATH.

However, both (POSIX) special:

break colon continue dot eval exec exit export

readonly return set shift times trap unset

And yash's semi-special (not special for POSIX):

alias bg cd command false fc fg getopts jobs

kill pwd read true umask unalias wait

builtins still work.

share|improve this answer

edited Jan 25 at 2:05

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

share|improve this answer

share|improve this answer

edited Jan 25 at 2:05

edited Jan 25 at 2:05

edited Jan 25 at 2:05

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

answered Jan 23 at 19:26

IsaacIsaac

12.1k11853

12.1k11853

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.

draft saved

draft discarded

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.

draft saved

draft discarded

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

Name

Email

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

Name

Email

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

Name

Email

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

Name

Email

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

Name

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

This page is only for reference, If you need detailed information, please check here