'n' in `IFS=$'n' is a variable?

up vote
1
down vote

favorite

I notice that to set newline IFS should with a $ as prefix

IFS=$'n'

but if set a colon, just

IFS=:

Is n is a variable?

asked 1 hour ago

rider dragon

27427

New contributor

add a commentÂ |Â

up vote
1
down vote

favorite

I notice that to set newline IFS should with a $ as prefix

IFS=$'n'

but if set a colon, just

IFS=:

Is n is a variable?

asked 1 hour ago

rider dragon

27427

New contributor

add a commentÂ |Â

up vote
1
down vote

favorite

I notice that to set newline IFS should with a $ as prefix

IFS=$'n'

but if set a colon, just

IFS=:

Is n is a variable?

asked 1 hour ago

rider dragon

27427

New contributor

I notice that to set newline IFS should with a $ as prefix

IFS=$'n'

but if set a colon, just

IFS=:

Is n is a variable?

bash

asked 1 hour ago

rider dragon

27427

New contributor

asked 1 hour ago

rider dragon

27427

New contributor

asked 1 hour ago

rider dragon

27427

New contributor

asked 1 hour ago

rider dragon

27427

asked 1 hour ago

rider dragon

27427

New contributor

rider dragon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

add a commentÂ |Â

3 Answers
3

active

oldest

votes

up vote
4
down vote

accepted

That $'...' is not parameter expansion, it's a special kind of quote introduced by ksh93 that expands those n, x0a, 12 codes to a newline character. zsh also added u000a. ksh93 and bash also have cj while zsh has C-J. ksh93 also supports variations like xa.

The $ is a cue that it is some form or expansion. But in any case, it differs from other forms of expansions that use $ (like $((1 + 1)), $param or $(cmd)) in that it is not performed inside double quotes or here documents (echo "$'x'" outputs $'x' in all shells though is unspecified per POSIX) and its expansion is not subject to split+glob, it's definitely closer to a quoting operator than an expansion operator.

IFS=n would set IFS to n ( is treated as a quoting operator) and IFS="n" or IFS='n' would set IFS to the two characters backslash and n.

You can also use:

IFS='
'

IFS="
"

IFS=$'
'

To pass a literal newline, though that's less legible (and one can't see other than using things like set list in vi whether $IFS contains other spacing characters in that code).

IFS=:, IFS=':', IFS=":", IFS=$':' all set IFS to : so it doesn't matter which you use.

$'...' is supported (with variations) by at least: ksh93, zsh, bash, mksh , busybox sh, FreeBSD sh. ksh93 and bash also have a $"..." form of quotes used for localisation of text though it's rarely used as it's cumbersome to deploy and use portably and reliably.

The es and fish shells can also use n outside of quotes to expand to newline.

Some tools like printf, some implementations of echo or awk can also expand those n by themselves. For instance, one can do:

printf 'n'
awk 'BEGINprintf "n"'
echo
echo 'nc' # UNIX compliant echos only

to output of newline character, but note that:


IFS=$(printf 'n')

won't work because command substitution ($(...)) strips all trailing newline characters. You can however use:

eval "$(printf 'IFS="n"')"

Which works because the output of printf ends in a " character, not a newline.

Now, for completeness, in the rc shell and derivatives (like es or akanga), $'n' is indeed the expansion of that n variable (a variable whose name is the sequence of two characters and n). Those shells don't have a limitation on what characters variable names may contain and only have one type of quotes: '...'.

$ rc
; 'n' = (foo bar)
; echo $'n'
foo bar
; echo $'n'(1)
foo

rc variables are also all exported to the environment, but at least in the Unix variant of rc, for variable names like n, the environment variable version undergoes a form of encoding:

; env | grep foo
__5cn=foobar

(0x5c being the byte value of ASCII ).

edited 1 min ago

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

@StefanHamcke In bash, using $"..." is slightly different from the same thing with single quotes. It "translates the string according to the current locale". To be honest, I've never seen this used.
â€“Â Kusalananda
52 mins ago

@StefanHamcke He also show this with double quotes, so yes. In this instance, the two would be identical.
â€“Â Kusalananda
27 mins ago

Yes, sorry, I added the IFS="[press Enter here]" after @Stefan added his comment, but didn't follow-up in comments. Yes, you can embed newlines in double quotes in Bourne-like shells.
â€“Â StÃ©phane Chazelas
23 mins ago

add a commentÂ |Â

up vote
2
down vote

Strings like $'n' have been introduced by ksh93 and are currently not part of the POSIX standard.

They allow to use most C alike escapes, e.g. $'u2345' and the escapes that are also supported by echo.

Note that if you do not like (in case of ksh93 or bash) to use that escape method, you still may use:

IFS='
'

which is equivalent but harder to read.

BTW: This extension already has passed the POSIX standard commitee, but it is scheduled for SUSv8 that is expected to appear not before the year 2020 because we first need to work on our lag behind the current list of bugs.

edited 59 mins ago

answered 1 hour ago

schily

10.2k31640

The $'...' expansions differ from that of echo. They're more like the ones for the format argument of printf. For echo, a 0 is required in 123 while for $'...' and printf format, 123 would be 12 a newline followed by a litteral 3.
â€“Â StÃ©phane Chazelas
1 hour ago

Note that the $'...' specification is still being discussed. There are several issues still to be resolved with the currently proposed wording.
â€“Â StÃ©phane Chazelas
1 hour ago

IIRC, It was closed but has been reopened. Due to the fact that there is still plenty of time before it becomes effective, I don't see a real problem with that.
â€“Â schily
1 hour ago

It was closed, I raised several objections, it was reopen, it was then amended, there are still several problems (most of them about uxxxx expansion), and no resolution in sight that would accommodate existing implementations. So it may not make it into the next POSIX version. Maybe they could leave the uxxxx expansion out for issue8, so we can still have at least $'n'.
â€“Â StÃ©phane Chazelas
54 mins ago

add a commentÂ |Â

up vote
1
down vote

This is ANSI-C quoting:

Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard.

Thus $'n' is replaced by a newline.

This is unrelated to shell parameter expansion, despite the use of $.

answered 1 hour ago

Stephen Kitt

152k23338406

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',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

rider dragon is a new contributor. Be nice, and check out our Code of Conduct.

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f477959%2fn-in-ifs-n-is-a-variable%23new-answer', 'question_page');

);

Post as a guest

Name

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

up vote
4
down vote

accepted

IFS=n would set IFS to n ( is treated as a quoting operator) and IFS="n" or IFS='n' would set IFS to the two characters backslash and n.

You can also use:

IFS='
'

IFS="
"

IFS=$'
'

To pass a literal newline, though that's less legible (and one can't see other than using things like set list in vi whether $IFS contains other spacing characters in that code).

IFS=:, IFS=':', IFS=":", IFS=$':' all set IFS to : so it doesn't matter which you use.

The es and fish shells can also use n outside of quotes to expand to newline.

Some tools like printf, some implementations of echo or awk can also expand those n by themselves. For instance, one can do:

printf 'n'
awk 'BEGINprintf "n"'
echo
echo 'nc' # UNIX compliant echos only

to output of newline character, but note that:


IFS=$(printf 'n')

won't work because command substitution ($(...)) strips all trailing newline characters. You can however use:

eval "$(printf 'IFS="n"')"

Which works because the output of printf ends in a " character, not a newline.

$ rc
; 'n' = (foo bar)
; echo $'n'
foo bar
; echo $'n'(1)
foo

rc variables are also all exported to the environment, but at least in the Unix variant of rc, for variable names like n, the environment variable version undergoes a form of encoding:

; env | grep foo
__5cn=foobar

(0x5c being the byte value of ASCII ).

edited 1 min ago

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

@StefanHamcke In bash, using $"..." is slightly different from the same thing with single quotes. It "translates the string according to the current locale". To be honest, I've never seen this used.
â€“Â Kusalananda
52 mins ago

@StefanHamcke He also show this with double quotes, so yes. In this instance, the two would be identical.
â€“Â Kusalananda
27 mins ago

Yes, sorry, I added the IFS="[press Enter here]" after @Stefan added his comment, but didn't follow-up in comments. Yes, you can embed newlines in double quotes in Bourne-like shells.
â€“Â StÃ©phane Chazelas
23 mins ago

add a commentÂ |Â

up vote
4
down vote

accepted

IFS=n would set IFS to n ( is treated as a quoting operator) and IFS="n" or IFS='n' would set IFS to the two characters backslash and n.

You can also use:

IFS='
'

IFS="
"

IFS=$'
'

To pass a literal newline, though that's less legible (and one can't see other than using things like set list in vi whether $IFS contains other spacing characters in that code).

IFS=:, IFS=':', IFS=":", IFS=$':' all set IFS to : so it doesn't matter which you use.

The es and fish shells can also use n outside of quotes to expand to newline.

Some tools like printf, some implementations of echo or awk can also expand those n by themselves. For instance, one can do:

printf 'n'
awk 'BEGINprintf "n"'
echo
echo 'nc' # UNIX compliant echos only

to output of newline character, but note that:


IFS=$(printf 'n')

won't work because command substitution ($(...)) strips all trailing newline characters. You can however use:

eval "$(printf 'IFS="n"')"

Which works because the output of printf ends in a " character, not a newline.

$ rc
; 'n' = (foo bar)
; echo $'n'
foo bar
; echo $'n'(1)
foo

rc variables are also all exported to the environment, but at least in the Unix variant of rc, for variable names like n, the environment variable version undergoes a form of encoding:

; env | grep foo
__5cn=foobar

(0x5c being the byte value of ASCII ).

edited 1 min ago

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

@StefanHamcke In bash, using $"..." is slightly different from the same thing with single quotes. It "translates the string according to the current locale". To be honest, I've never seen this used.
â€“Â Kusalananda
52 mins ago

@StefanHamcke He also show this with double quotes, so yes. In this instance, the two would be identical.
â€“Â Kusalananda
27 mins ago

Yes, sorry, I added the IFS="[press Enter here]" after @Stefan added his comment, but didn't follow-up in comments. Yes, you can embed newlines in double quotes in Bourne-like shells.
â€“Â StÃ©phane Chazelas
23 mins ago

add a commentÂ |Â

up vote
4
down vote

accepted

IFS=n would set IFS to n ( is treated as a quoting operator) and IFS="n" or IFS='n' would set IFS to the two characters backslash and n.

You can also use:

IFS='
'

IFS="
"

IFS=$'
'

To pass a literal newline, though that's less legible (and one can't see other than using things like set list in vi whether $IFS contains other spacing characters in that code).

IFS=:, IFS=':', IFS=":", IFS=$':' all set IFS to : so it doesn't matter which you use.

The es and fish shells can also use n outside of quotes to expand to newline.

Some tools like printf, some implementations of echo or awk can also expand those n by themselves. For instance, one can do:

printf 'n'
awk 'BEGINprintf "n"'
echo
echo 'nc' # UNIX compliant echos only

to output of newline character, but note that:


IFS=$(printf 'n')

won't work because command substitution ($(...)) strips all trailing newline characters. You can however use:

eval "$(printf 'IFS="n"')"

Which works because the output of printf ends in a " character, not a newline.

$ rc
; 'n' = (foo bar)
; echo $'n'
foo bar
; echo $'n'(1)
foo

rc variables are also all exported to the environment, but at least in the Unix variant of rc, for variable names like n, the environment variable version undergoes a form of encoding:

; env | grep foo
__5cn=foobar

(0x5c being the byte value of ASCII ).

edited 1 min ago

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

IFS=n would set IFS to n ( is treated as a quoting operator) and IFS="n" or IFS='n' would set IFS to the two characters backslash and n.

You can also use:

IFS='
'

IFS="
"

IFS=$'
'

To pass a literal newline, though that's less legible (and one can't see other than using things like set list in vi whether $IFS contains other spacing characters in that code).

IFS=:, IFS=':', IFS=":", IFS=$':' all set IFS to : so it doesn't matter which you use.

The es and fish shells can also use n outside of quotes to expand to newline.

Some tools like printf, some implementations of echo or awk can also expand those n by themselves. For instance, one can do:

printf 'n'
awk 'BEGINprintf "n"'
echo
echo 'nc' # UNIX compliant echos only

to output of newline character, but note that:


IFS=$(printf 'n')

won't work because command substitution ($(...)) strips all trailing newline characters. You can however use:

eval "$(printf 'IFS="n"')"

Which works because the output of printf ends in a " character, not a newline.

$ rc
; 'n' = (foo bar)
; echo $'n'
foo bar
; echo $'n'(1)
foo

rc variables are also all exported to the environment, but at least in the Unix variant of rc, for variable names like n, the environment variable version undergoes a form of encoding:

; env | grep foo
__5cn=foobar

(0x5c being the byte value of ASCII ).

edited 1 min ago

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

edited 1 min ago

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

answered 1 hour ago

StÃ©phane Chazelas

290k54539876

@StefanHamcke In bash, using $"..." is slightly different from the same thing with single quotes. It "translates the string according to the current locale". To be honest, I've never seen this used.
â€“Â Kusalananda
52 mins ago

@StefanHamcke He also show this with double quotes, so yes. In this instance, the two would be identical.
â€“Â Kusalananda
27 mins ago

Yes, sorry, I added the IFS="[press Enter here]" after @Stefan added his comment, but didn't follow-up in comments. Yes, you can embed newlines in double quotes in Bourne-like shells.
â€“Â StÃ©phane Chazelas
23 mins ago

add a commentÂ |Â

@StefanHamcke In bash, using $"..." is slightly different from the same thing with single quotes. It "translates the string according to the current locale". To be honest, I've never seen this used.
â€“Â Kusalananda
52 mins ago

@StefanHamcke He also show this with double quotes, so yes. In this instance, the two would be identical.
â€“Â Kusalananda
27 mins ago

Yes, sorry, I added the IFS="[press Enter here]" after @Stefan added his comment, but didn't follow-up in comments. Yes, you can embed newlines in double quotes in Bourne-like shells.
â€“Â StÃ©phane Chazelas
23 mins ago

@StefanHamcke In bash, using $"..." is slightly different from the same thing with single quotes. It "translates the string according to the current locale". To be honest, I've never seen this used.
â€“Â Kusalananda
52 mins ago

@StefanHamcke He also show this with double quotes, so yes. In this instance, the two would be identical.
â€“Â Kusalananda
27 mins ago

Yes, sorry, I added the IFS="[press Enter here]" after @Stefan added his comment, but didn't follow-up in comments. Yes, you can embed newlines in double quotes in Bourne-like shells.
â€“Â StÃ©phane Chazelas
23 mins ago

add a commentÂ |Â

up vote
2
down vote

Strings like $'n' have been introduced by ksh93 and are currently not part of the POSIX standard.

They allow to use most C alike escapes, e.g. $'u2345' and the escapes that are also supported by echo.

Note that if you do not like (in case of ksh93 or bash) to use that escape method, you still may use:

IFS='
'

which is equivalent but harder to read.

edited 59 mins ago

answered 1 hour ago

schily

10.2k31640

The $'...' expansions differ from that of echo. They're more like the ones for the format argument of printf. For echo, a 0 is required in 123 while for $'...' and printf format, 123 would be 12 a newline followed by a litteral 3.
â€“Â StÃ©phane Chazelas
1 hour ago

Note that the $'...' specification is still being discussed. There are several issues still to be resolved with the currently proposed wording.
â€“Â StÃ©phane Chazelas
1 hour ago

IIRC, It was closed but has been reopened. Due to the fact that there is still plenty of time before it becomes effective, I don't see a real problem with that.
â€“Â schily
1 hour ago

It was closed, I raised several objections, it was reopen, it was then amended, there are still several problems (most of them about uxxxx expansion), and no resolution in sight that would accommodate existing implementations. So it may not make it into the next POSIX version. Maybe they could leave the uxxxx expansion out for issue8, so we can still have at least $'n'.
â€“Â StÃ©phane Chazelas
54 mins ago

add a commentÂ |Â

up vote
2
down vote

Strings like $'n' have been introduced by ksh93 and are currently not part of the POSIX standard.

They allow to use most C alike escapes, e.g. $'u2345' and the escapes that are also supported by echo.

Note that if you do not like (in case of ksh93 or bash) to use that escape method, you still may use:

IFS='
'

which is equivalent but harder to read.

edited 59 mins ago

answered 1 hour ago

schily

10.2k31640

The $'...' expansions differ from that of echo. They're more like the ones for the format argument of printf. For echo, a 0 is required in 123 while for $'...' and printf format, 123 would be 12 a newline followed by a litteral 3.
â€“Â StÃ©phane Chazelas
1 hour ago

Note that the $'...' specification is still being discussed. There are several issues still to be resolved with the currently proposed wording.
â€“Â StÃ©phane Chazelas
1 hour ago

IIRC, It was closed but has been reopened. Due to the fact that there is still plenty of time before it becomes effective, I don't see a real problem with that.
â€“Â schily
1 hour ago

It was closed, I raised several objections, it was reopen, it was then amended, there are still several problems (most of them about uxxxx expansion), and no resolution in sight that would accommodate existing implementations. So it may not make it into the next POSIX version. Maybe they could leave the uxxxx expansion out for issue8, so we can still have at least $'n'.
â€“Â StÃ©phane Chazelas
54 mins ago

add a commentÂ |Â

up vote
2
down vote

Strings like $'n' have been introduced by ksh93 and are currently not part of the POSIX standard.

They allow to use most C alike escapes, e.g. $'u2345' and the escapes that are also supported by echo.

Note that if you do not like (in case of ksh93 or bash) to use that escape method, you still may use:

IFS='
'

which is equivalent but harder to read.

edited 59 mins ago

answered 1 hour ago

schily

10.2k31640

Strings like $'n' have been introduced by ksh93 and are currently not part of the POSIX standard.

They allow to use most C alike escapes, e.g. $'u2345' and the escapes that are also supported by echo.

Note that if you do not like (in case of ksh93 or bash) to use that escape method, you still may use:

IFS='
'

which is equivalent but harder to read.

edited 59 mins ago

answered 1 hour ago

schily

10.2k31640

edited 59 mins ago

answered 1 hour ago

schily

10.2k31640

answered 1 hour ago

schily

10.2k31640

answered 1 hour ago

schily

10.2k31640

The $'...' expansions differ from that of echo. They're more like the ones for the format argument of printf. For echo, a 0 is required in 123 while for $'...' and printf format, 123 would be 12 a newline followed by a litteral 3.
â€“Â StÃ©phane Chazelas
1 hour ago

Note that the $'...' specification is still being discussed. There are several issues still to be resolved with the currently proposed wording.
â€“Â StÃ©phane Chazelas
1 hour ago

IIRC, It was closed but has been reopened. Due to the fact that there is still plenty of time before it becomes effective, I don't see a real problem with that.
â€“Â schily
1 hour ago

It was closed, I raised several objections, it was reopen, it was then amended, there are still several problems (most of them about uxxxx expansion), and no resolution in sight that would accommodate existing implementations. So it may not make it into the next POSIX version. Maybe they could leave the uxxxx expansion out for issue8, so we can still have at least $'n'.
â€“Â StÃ©phane Chazelas
54 mins ago

add a commentÂ |Â

The $'...' expansions differ from that of echo. They're more like the ones for the format argument of printf. For echo, a 0 is required in 123 while for $'...' and printf format, 123 would be 12 a newline followed by a litteral 3.
â€“Â StÃ©phane Chazelas
1 hour ago

Note that the $'...' specification is still being discussed. There are several issues still to be resolved with the currently proposed wording.
â€“Â StÃ©phane Chazelas
1 hour ago

IIRC, It was closed but has been reopened. Due to the fact that there is still plenty of time before it becomes effective, I don't see a real problem with that.
â€“Â schily
1 hour ago

It was closed, I raised several objections, it was reopen, it was then amended, there are still several problems (most of them about uxxxx expansion), and no resolution in sight that would accommodate existing implementations. So it may not make it into the next POSIX version. Maybe they could leave the uxxxx expansion out for issue8, so we can still have at least $'n'.
â€“Â StÃ©phane Chazelas
54 mins ago

The $'...' expansions differ from that of echo. They're more like the ones for the format argument of printf. For echo, a 0 is required in 123 while for $'...' and printf format, 123 would be 12 a newline followed by a litteral 3.
â€“Â StÃ©phane Chazelas
1 hour ago

Note that the $'...' specification is still being discussed. There are several issues still to be resolved with the currently proposed wording.
â€“Â StÃ©phane Chazelas
1 hour ago

IIRC, It was closed but has been reopened. Due to the fact that there is still plenty of time before it becomes effective, I don't see a real problem with that.
â€“Â schily
1 hour ago

It was closed, I raised several objections, it was reopen, it was then amended, there are still several problems (most of them about uxxxx expansion), and no resolution in sight that would accommodate existing implementations. So it may not make it into the next POSIX version. Maybe they could leave the uxxxx expansion out for issue8, so we can still have at least $'n'.
â€“Â StÃ©phane Chazelas
54 mins ago

add a commentÂ |Â

up vote
1
down vote

This is ANSI-C quoting:

Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard.

Thus $'n' is replaced by a newline.

This is unrelated to shell parameter expansion, despite the use of $.

answered 1 hour ago

Stephen Kitt

152k23338406

add a commentÂ |Â

up vote
1
down vote

This is ANSI-C quoting:

Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard.

Thus $'n' is replaced by a newline.

This is unrelated to shell parameter expansion, despite the use of $.

answered 1 hour ago

Stephen Kitt

152k23338406

add a commentÂ |Â

up vote
1
down vote

This is ANSI-C quoting:

Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard.

Thus $'n' is replaced by a newline.

This is unrelated to shell parameter expansion, despite the use of $.

answered 1 hour ago

Stephen Kitt

152k23338406

This is ANSI-C quoting:

Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard.

Thus $'n' is replaced by a newline.

This is unrelated to shell parameter expansion, despite the use of $.

answered 1 hour ago

Stephen Kitt

152k23338406

answered 1 hour ago

Stephen Kitt

152k23338406

answered 1 hour ago

Stephen Kitt

152k23338406

answered 1 hour ago

Stephen Kitt

152k23338406

add a commentÂ |Â

rider dragon is a new contributor. Be nice, and check out our Code of Conduct.

draft saved

draft discarded

rider dragon is a new contributor. Be nice, and check out our Code of Conduct.

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky