Why doesn't echo -n work in shell on Mac?












1














The man page for echo says:



 -n    Do not print the trailing newline character.  This may also be
achieved by appending `c' to the end of the string, as is done by
iBCS2 compatible systems. Note that this option as well as the
effect of `c' are implementation-defined in IEEE Std 1003.1-2001
(``POSIX.1'') as amended by Cor. 1-2002. Applications aiming for
maximum portability are strongly encouraged to use printf(1) to
suppress the newline character.


However this doesn't seem to work in sh on Mac:



sh-3.2$ echo $0
/bin/sh
sh-3.2$ which echo
/bin/echo
sh-3.2$ echo -n foo
-n foo


It works properly in bash:



bash-3.2$ echo $0
bash
bash-3.2$ which echo
/bin/echo
bash-3.2$ echo -n foo
foobash-3.2


FWIW this only seems to happen on Mac, on Linux it works properly:



$ echo $0
sh
$ echo -n foo
foo$









share|improve this question
























  • If the shell provides a built-in echo, it'll run that instead of /bin/echo – check with type echo instead of which echo to see if it's a built-in.
    – Benjamin W.
    Nov 21 '18 at 18:41












  • Ah, thanks. It was confusing because I assumed man echo was pulling up the correct version.
    – jjj
    Nov 21 '18 at 18:50












  • Macs are not FreeBSD. Macs are UNIX and OSX though they do contain components of FreeBSD userland.
    – Rob
    Dec 6 '18 at 13:40


















1














The man page for echo says:



 -n    Do not print the trailing newline character.  This may also be
achieved by appending `c' to the end of the string, as is done by
iBCS2 compatible systems. Note that this option as well as the
effect of `c' are implementation-defined in IEEE Std 1003.1-2001
(``POSIX.1'') as amended by Cor. 1-2002. Applications aiming for
maximum portability are strongly encouraged to use printf(1) to
suppress the newline character.


However this doesn't seem to work in sh on Mac:



sh-3.2$ echo $0
/bin/sh
sh-3.2$ which echo
/bin/echo
sh-3.2$ echo -n foo
-n foo


It works properly in bash:



bash-3.2$ echo $0
bash
bash-3.2$ which echo
/bin/echo
bash-3.2$ echo -n foo
foobash-3.2


FWIW this only seems to happen on Mac, on Linux it works properly:



$ echo $0
sh
$ echo -n foo
foo$









share|improve this question
























  • If the shell provides a built-in echo, it'll run that instead of /bin/echo – check with type echo instead of which echo to see if it's a built-in.
    – Benjamin W.
    Nov 21 '18 at 18:41












  • Ah, thanks. It was confusing because I assumed man echo was pulling up the correct version.
    – jjj
    Nov 21 '18 at 18:50












  • Macs are not FreeBSD. Macs are UNIX and OSX though they do contain components of FreeBSD userland.
    – Rob
    Dec 6 '18 at 13:40
















1












1








1







The man page for echo says:



 -n    Do not print the trailing newline character.  This may also be
achieved by appending `c' to the end of the string, as is done by
iBCS2 compatible systems. Note that this option as well as the
effect of `c' are implementation-defined in IEEE Std 1003.1-2001
(``POSIX.1'') as amended by Cor. 1-2002. Applications aiming for
maximum portability are strongly encouraged to use printf(1) to
suppress the newline character.


However this doesn't seem to work in sh on Mac:



sh-3.2$ echo $0
/bin/sh
sh-3.2$ which echo
/bin/echo
sh-3.2$ echo -n foo
-n foo


It works properly in bash:



bash-3.2$ echo $0
bash
bash-3.2$ which echo
/bin/echo
bash-3.2$ echo -n foo
foobash-3.2


FWIW this only seems to happen on Mac, on Linux it works properly:



$ echo $0
sh
$ echo -n foo
foo$









share|improve this question















The man page for echo says:



 -n    Do not print the trailing newline character.  This may also be
achieved by appending `c' to the end of the string, as is done by
iBCS2 compatible systems. Note that this option as well as the
effect of `c' are implementation-defined in IEEE Std 1003.1-2001
(``POSIX.1'') as amended by Cor. 1-2002. Applications aiming for
maximum portability are strongly encouraged to use printf(1) to
suppress the newline character.


However this doesn't seem to work in sh on Mac:



sh-3.2$ echo $0
/bin/sh
sh-3.2$ which echo
/bin/echo
sh-3.2$ echo -n foo
-n foo


It works properly in bash:



bash-3.2$ echo $0
bash
bash-3.2$ which echo
/bin/echo
bash-3.2$ echo -n foo
foobash-3.2


FWIW this only seems to happen on Mac, on Linux it works properly:



$ echo $0
sh
$ echo -n foo
foo$






bash macos unix sh






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 6 '18 at 13:40









Rob

11.5k82852




11.5k82852










asked Nov 21 '18 at 18:39









jjjjjj

400413




400413












  • If the shell provides a built-in echo, it'll run that instead of /bin/echo – check with type echo instead of which echo to see if it's a built-in.
    – Benjamin W.
    Nov 21 '18 at 18:41












  • Ah, thanks. It was confusing because I assumed man echo was pulling up the correct version.
    – jjj
    Nov 21 '18 at 18:50












  • Macs are not FreeBSD. Macs are UNIX and OSX though they do contain components of FreeBSD userland.
    – Rob
    Dec 6 '18 at 13:40




















  • If the shell provides a built-in echo, it'll run that instead of /bin/echo – check with type echo instead of which echo to see if it's a built-in.
    – Benjamin W.
    Nov 21 '18 at 18:41












  • Ah, thanks. It was confusing because I assumed man echo was pulling up the correct version.
    – jjj
    Nov 21 '18 at 18:50












  • Macs are not FreeBSD. Macs are UNIX and OSX though they do contain components of FreeBSD userland.
    – Rob
    Dec 6 '18 at 13:40


















If the shell provides a built-in echo, it'll run that instead of /bin/echo – check with type echo instead of which echo to see if it's a built-in.
– Benjamin W.
Nov 21 '18 at 18:41






If the shell provides a built-in echo, it'll run that instead of /bin/echo – check with type echo instead of which echo to see if it's a built-in.
– Benjamin W.
Nov 21 '18 at 18:41














Ah, thanks. It was confusing because I assumed man echo was pulling up the correct version.
– jjj
Nov 21 '18 at 18:50






Ah, thanks. It was confusing because I assumed man echo was pulling up the correct version.
– jjj
Nov 21 '18 at 18:50














Macs are not FreeBSD. Macs are UNIX and OSX though they do contain components of FreeBSD userland.
– Rob
Dec 6 '18 at 13:40






Macs are not FreeBSD. Macs are UNIX and OSX though they do contain components of FreeBSD userland.
– Rob
Dec 6 '18 at 13:40














1 Answer
1






active

oldest

votes


















3














-n is a bash extension to echo. In version 3.2 (which ships with macOS), bash does not support the extension when invoked as sh. Starting with version 4.0 (some version of which is likely on your Linux box), bash does honor -n when invoked as sh.



Update: the xpg_echo option determines if bash's built-in echo is POSIX-compliant or not. In bash 3.2 (or at least the macOS build of 3.2), this option defaults to on; in bash 4.x, it defaults to off.



% sh -c 'shopt xpg_echo'
xpg_echo on
% ./sh -c 'shopt xpg_echo'
xpg_echo off


(./sh is a symlink to /usr/local/bin/bash, a local installation of bash 4.4 on my machine.)






share|improve this answer



















  • 1




    Doesn't that depend on the xpg_echo option? See item 52 in gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode
    – Benjamin W.
    Nov 21 '18 at 18:44










  • That also comes into play; I'm not sure if it being enabled by default is the difference between 3.2 and 4.x when bash is invoked as sh.
    – chepner
    Nov 21 '18 at 18:45










  • According to NEWS, xpg_echo was introduced in 2.04, and its behaviour being affected by POSIX mode was changed in 3.1. Can't find any changes in 3.2 or later, though.
    – Benjamin W.
    Nov 21 '18 at 18:52










  • Then why does man sh show -n as a valid option for echo?
    – jjj
    Nov 21 '18 at 18:53






  • 2




    Not really. The best thing to do is simply avoid echo altogether, and use printf, the behavior of which is much more predictable.
    – chepner
    Nov 21 '18 at 19:07











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418600%2fwhy-doesnt-echo-n-work-in-shell-on-mac%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














-n is a bash extension to echo. In version 3.2 (which ships with macOS), bash does not support the extension when invoked as sh. Starting with version 4.0 (some version of which is likely on your Linux box), bash does honor -n when invoked as sh.



Update: the xpg_echo option determines if bash's built-in echo is POSIX-compliant or not. In bash 3.2 (or at least the macOS build of 3.2), this option defaults to on; in bash 4.x, it defaults to off.



% sh -c 'shopt xpg_echo'
xpg_echo on
% ./sh -c 'shopt xpg_echo'
xpg_echo off


(./sh is a symlink to /usr/local/bin/bash, a local installation of bash 4.4 on my machine.)






share|improve this answer



















  • 1




    Doesn't that depend on the xpg_echo option? See item 52 in gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode
    – Benjamin W.
    Nov 21 '18 at 18:44










  • That also comes into play; I'm not sure if it being enabled by default is the difference between 3.2 and 4.x when bash is invoked as sh.
    – chepner
    Nov 21 '18 at 18:45










  • According to NEWS, xpg_echo was introduced in 2.04, and its behaviour being affected by POSIX mode was changed in 3.1. Can't find any changes in 3.2 or later, though.
    – Benjamin W.
    Nov 21 '18 at 18:52










  • Then why does man sh show -n as a valid option for echo?
    – jjj
    Nov 21 '18 at 18:53






  • 2




    Not really. The best thing to do is simply avoid echo altogether, and use printf, the behavior of which is much more predictable.
    – chepner
    Nov 21 '18 at 19:07
















3














-n is a bash extension to echo. In version 3.2 (which ships with macOS), bash does not support the extension when invoked as sh. Starting with version 4.0 (some version of which is likely on your Linux box), bash does honor -n when invoked as sh.



Update: the xpg_echo option determines if bash's built-in echo is POSIX-compliant or not. In bash 3.2 (or at least the macOS build of 3.2), this option defaults to on; in bash 4.x, it defaults to off.



% sh -c 'shopt xpg_echo'
xpg_echo on
% ./sh -c 'shopt xpg_echo'
xpg_echo off


(./sh is a symlink to /usr/local/bin/bash, a local installation of bash 4.4 on my machine.)






share|improve this answer



















  • 1




    Doesn't that depend on the xpg_echo option? See item 52 in gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode
    – Benjamin W.
    Nov 21 '18 at 18:44










  • That also comes into play; I'm not sure if it being enabled by default is the difference between 3.2 and 4.x when bash is invoked as sh.
    – chepner
    Nov 21 '18 at 18:45










  • According to NEWS, xpg_echo was introduced in 2.04, and its behaviour being affected by POSIX mode was changed in 3.1. Can't find any changes in 3.2 or later, though.
    – Benjamin W.
    Nov 21 '18 at 18:52










  • Then why does man sh show -n as a valid option for echo?
    – jjj
    Nov 21 '18 at 18:53






  • 2




    Not really. The best thing to do is simply avoid echo altogether, and use printf, the behavior of which is much more predictable.
    – chepner
    Nov 21 '18 at 19:07














3












3








3






-n is a bash extension to echo. In version 3.2 (which ships with macOS), bash does not support the extension when invoked as sh. Starting with version 4.0 (some version of which is likely on your Linux box), bash does honor -n when invoked as sh.



Update: the xpg_echo option determines if bash's built-in echo is POSIX-compliant or not. In bash 3.2 (or at least the macOS build of 3.2), this option defaults to on; in bash 4.x, it defaults to off.



% sh -c 'shopt xpg_echo'
xpg_echo on
% ./sh -c 'shopt xpg_echo'
xpg_echo off


(./sh is a symlink to /usr/local/bin/bash, a local installation of bash 4.4 on my machine.)






share|improve this answer














-n is a bash extension to echo. In version 3.2 (which ships with macOS), bash does not support the extension when invoked as sh. Starting with version 4.0 (some version of which is likely on your Linux box), bash does honor -n when invoked as sh.



Update: the xpg_echo option determines if bash's built-in echo is POSIX-compliant or not. In bash 3.2 (or at least the macOS build of 3.2), this option defaults to on; in bash 4.x, it defaults to off.



% sh -c 'shopt xpg_echo'
xpg_echo on
% ./sh -c 'shopt xpg_echo'
xpg_echo off


(./sh is a symlink to /usr/local/bin/bash, a local installation of bash 4.4 on my machine.)







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 21 '18 at 18:49

























answered Nov 21 '18 at 18:43









chepnerchepner

245k32232323




245k32232323








  • 1




    Doesn't that depend on the xpg_echo option? See item 52 in gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode
    – Benjamin W.
    Nov 21 '18 at 18:44










  • That also comes into play; I'm not sure if it being enabled by default is the difference between 3.2 and 4.x when bash is invoked as sh.
    – chepner
    Nov 21 '18 at 18:45










  • According to NEWS, xpg_echo was introduced in 2.04, and its behaviour being affected by POSIX mode was changed in 3.1. Can't find any changes in 3.2 or later, though.
    – Benjamin W.
    Nov 21 '18 at 18:52










  • Then why does man sh show -n as a valid option for echo?
    – jjj
    Nov 21 '18 at 18:53






  • 2




    Not really. The best thing to do is simply avoid echo altogether, and use printf, the behavior of which is much more predictable.
    – chepner
    Nov 21 '18 at 19:07














  • 1




    Doesn't that depend on the xpg_echo option? See item 52 in gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode
    – Benjamin W.
    Nov 21 '18 at 18:44










  • That also comes into play; I'm not sure if it being enabled by default is the difference between 3.2 and 4.x when bash is invoked as sh.
    – chepner
    Nov 21 '18 at 18:45










  • According to NEWS, xpg_echo was introduced in 2.04, and its behaviour being affected by POSIX mode was changed in 3.1. Can't find any changes in 3.2 or later, though.
    – Benjamin W.
    Nov 21 '18 at 18:52










  • Then why does man sh show -n as a valid option for echo?
    – jjj
    Nov 21 '18 at 18:53






  • 2




    Not really. The best thing to do is simply avoid echo altogether, and use printf, the behavior of which is much more predictable.
    – chepner
    Nov 21 '18 at 19:07








1




1




Doesn't that depend on the xpg_echo option? See item 52 in gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode
– Benjamin W.
Nov 21 '18 at 18:44




Doesn't that depend on the xpg_echo option? See item 52 in gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode
– Benjamin W.
Nov 21 '18 at 18:44












That also comes into play; I'm not sure if it being enabled by default is the difference between 3.2 and 4.x when bash is invoked as sh.
– chepner
Nov 21 '18 at 18:45




That also comes into play; I'm not sure if it being enabled by default is the difference between 3.2 and 4.x when bash is invoked as sh.
– chepner
Nov 21 '18 at 18:45












According to NEWS, xpg_echo was introduced in 2.04, and its behaviour being affected by POSIX mode was changed in 3.1. Can't find any changes in 3.2 or later, though.
– Benjamin W.
Nov 21 '18 at 18:52




According to NEWS, xpg_echo was introduced in 2.04, and its behaviour being affected by POSIX mode was changed in 3.1. Can't find any changes in 3.2 or later, though.
– Benjamin W.
Nov 21 '18 at 18:52












Then why does man sh show -n as a valid option for echo?
– jjj
Nov 21 '18 at 18:53




Then why does man sh show -n as a valid option for echo?
– jjj
Nov 21 '18 at 18:53




2




2




Not really. The best thing to do is simply avoid echo altogether, and use printf, the behavior of which is much more predictable.
– chepner
Nov 21 '18 at 19:07




Not really. The best thing to do is simply avoid echo altogether, and use printf, the behavior of which is much more predictable.
– chepner
Nov 21 '18 at 19:07


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


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





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418600%2fwhy-doesnt-echo-n-work-in-shell-on-mac%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

404 Error Contact Form 7 ajax form submitting

How to know if a Active Directory user can login interactively

TypeError: fit_transform() missing 1 required positional argument: 'X'