Cannot “cd” or change directory using bash script in WSL [duplicate]

Clash Royale CLAN TAG#URR8PPP

up vote
12
down vote

favorite

1

This question already has an answer here:

• 
  How do I fix “$'r': command not found” errors running Bash scripts in WSL?
  
  2 answers
  
  

I installed Ubuntu bash on my windows machine, so I can test linux scripts away from work. I created a very simple script with basic "hello world" and a change directory (cd), but when executing it displays the hello world. It errors out on the cd to directory line.

Here is the error:

$ ./test.sh
hello world
zipping away
./test.sh: line 6: cd: $'/home/fjaffer/temprr': No such file or directory
./test.sh: line 7: $'r': command not found
ffr@DP-PC:~$

My script test.sh is below:

#!/bin/bash
echo "hello world"
echo "zipping away"
dir=/home/fjaffer/temp
cd $dir

Please advise?
Thank you.

command-line bash scripts windows-subsystem-for-linux

share|improve this question

edited Sep 3 at 13:43

αғsнιη

23.2k2191152

asked Sep 2 at 15:23

Femina Jaffer

834

marked as duplicate by David Foerster, Melebius, George Udosen, Thomas, Zanna command-line
Users with the  command-line badge can single-handedly close command-line questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Sep 3 at 19:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You'd normally want to use cd "$dir" instead of letting the shell word-split the expansion of "$dir". Surprised that didn't consume the r characters.
  – Peter Cordes
  Sep 2 at 16:23
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  @PeterCordes, the carriage return isn't contained in the default IFS (and it's not "IFS white space"), so it acts like any character, just invisible.
  – ilkkachu
  Sep 2 at 16:57
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Using cd in a script file and executing that script as a command (just specifying its name e.g. ./test.sh) won't do what you expect - the script runs in a subprocess, and the directory will be changed in that process, but not in your interactive shell. Using ". test.sh" uses the "." shell command to have your current interactive shell run the commands in the script, which will change the directory as you're expecting. (NOTE: this is how it works in Linux, things may be different in WSL.)
  – Randy Orrison
  Sep 3 at 7:39
  

  
  
  
  

add a comment | 

up vote
12
down vote

favorite

1

This question already has an answer here:

• 
  How do I fix “$'r': command not found” errors running Bash scripts in WSL?
  
  2 answers
  
  

I installed Ubuntu bash on my windows machine, so I can test linux scripts away from work. I created a very simple script with basic "hello world" and a change directory (cd), but when executing it displays the hello world. It errors out on the cd to directory line.

Here is the error:

$ ./test.sh
hello world
zipping away
./test.sh: line 6: cd: $'/home/fjaffer/temprr': No such file or directory
./test.sh: line 7: $'r': command not found
ffr@DP-PC:~$

My script test.sh is below:

#!/bin/bash
echo "hello world"
echo "zipping away"
dir=/home/fjaffer/temp
cd $dir

Please advise?
Thank you.

command-line bash scripts windows-subsystem-for-linux

share|improve this question

edited Sep 3 at 13:43

αғsнιη

23.2k2191152

asked Sep 2 at 15:23

Femina Jaffer

834

marked as duplicate by David Foerster, Melebius, George Udosen, Thomas, Zanna command-line
Users with the  command-line badge can single-handedly close command-line questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Sep 3 at 19:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You'd normally want to use cd "$dir" instead of letting the shell word-split the expansion of "$dir". Surprised that didn't consume the r characters.
  – Peter Cordes
  Sep 2 at 16:23
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  @PeterCordes, the carriage return isn't contained in the default IFS (and it's not "IFS white space"), so it acts like any character, just invisible.
  – ilkkachu
  Sep 2 at 16:57
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Using cd in a script file and executing that script as a command (just specifying its name e.g. ./test.sh) won't do what you expect - the script runs in a subprocess, and the directory will be changed in that process, but not in your interactive shell. Using ". test.sh" uses the "." shell command to have your current interactive shell run the commands in the script, which will change the directory as you're expecting. (NOTE: this is how it works in Linux, things may be different in WSL.)
  – Randy Orrison
  Sep 3 at 7:39
  

  
  
  
  

add a comment | 

up vote
12
down vote

favorite

1

up vote
12
down vote

favorite

1

1

This question already has an answer here:

• 
  How do I fix “$'r': command not found” errors running Bash scripts in WSL?
  
  2 answers
  
  

I installed Ubuntu bash on my windows machine, so I can test linux scripts away from work. I created a very simple script with basic "hello world" and a change directory (cd), but when executing it displays the hello world. It errors out on the cd to directory line.

Here is the error:

$ ./test.sh
hello world
zipping away
./test.sh: line 6: cd: $'/home/fjaffer/temprr': No such file or directory
./test.sh: line 7: $'r': command not found
ffr@DP-PC:~$

My script test.sh is below:

#!/bin/bash
echo "hello world"
echo "zipping away"
dir=/home/fjaffer/temp
cd $dir

Please advise?
Thank you.

command-line bash scripts windows-subsystem-for-linux

share|improve this question

edited Sep 3 at 13:43

αғsнιη

23.2k2191152

asked Sep 2 at 15:23

Femina Jaffer

834

This question already has an answer here:

• 
  How do I fix “$'r': command not found” errors running Bash scripts in WSL?
  
  2 answers
  
  

I installed Ubuntu bash on my windows machine, so I can test linux scripts away from work. I created a very simple script with basic "hello world" and a change directory (cd), but when executing it displays the hello world. It errors out on the cd to directory line.

Here is the error:

$ ./test.sh
hello world
zipping away
./test.sh: line 6: cd: $'/home/fjaffer/temprr': No such file or directory
./test.sh: line 7: $'r': command not found
ffr@DP-PC:~$

My script test.sh is below:

#!/bin/bash
echo "hello world"
echo "zipping away"
dir=/home/fjaffer/temp
cd $dir

Please advise?
Thank you.

This question already has an answer here:

• 
  How do I fix “$'r': command not found” errors running Bash scripts in WSL?
  
  2 answers
  
  

command-line bash scripts windows-subsystem-for-linux

share|improve this question

edited Sep 3 at 13:43

αғsнιη

23.2k2191152

asked Sep 2 at 15:23

Femina Jaffer

834

share|improve this question

share|improve this question

edited Sep 3 at 13:43

αғsнιη

23.2k2191152

edited Sep 3 at 13:43

αғsнιη

23.2k2191152

edited Sep 3 at 13:43

αғsнιη

23.2k2191152

23.2k2191152

asked Sep 2 at 15:23

Femina Jaffer

834

asked Sep 2 at 15:23

Femina Jaffer

834

asked Sep 2 at 15:23

Femina Jaffer

834

834

marked as duplicate by David Foerster, Melebius, George Udosen, Thomas, Zanna command-line
Users with the  command-line badge can single-handedly close command-line questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Sep 3 at 19:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

marked as duplicate by David Foerster, Melebius, George Udosen, Thomas, Zanna command-line
Users with the  command-line badge can single-handedly close command-line questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Sep 3 at 19:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You'd normally want to use cd "$dir" instead of letting the shell word-split the expansion of "$dir". Surprised that didn't consume the r characters.
  – Peter Cordes
  Sep 2 at 16:23
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  @PeterCordes, the carriage return isn't contained in the default IFS (and it's not "IFS white space"), so it acts like any character, just invisible.
  – ilkkachu
  Sep 2 at 16:57
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Using cd in a script file and executing that script as a command (just specifying its name e.g. ./test.sh) won't do what you expect - the script runs in a subprocess, and the directory will be changed in that process, but not in your interactive shell. Using ". test.sh" uses the "." shell command to have your current interactive shell run the commands in the script, which will change the directory as you're expecting. (NOTE: this is how it works in Linux, things may be different in WSL.)
  – Randy Orrison
  Sep 3 at 7:39
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  You'd normally want to use cd "$dir" instead of letting the shell word-split the expansion of "$dir". Surprised that didn't consume the r characters.
  – Peter Cordes
  Sep 2 at 16:23
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  @PeterCordes, the carriage return isn't contained in the default IFS (and it's not "IFS white space"), so it acts like any character, just invisible.
  – ilkkachu
  Sep 2 at 16:57
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Using cd in a script file and executing that script as a command (just specifying its name e.g. ./test.sh) won't do what you expect - the script runs in a subprocess, and the directory will be changed in that process, but not in your interactive shell. Using ". test.sh" uses the "." shell command to have your current interactive shell run the commands in the script, which will change the directory as you're expecting. (NOTE: this is how it works in Linux, things may be different in WSL.)
  – Randy Orrison
  Sep 3 at 7:39
  

  
  
  
  

You'd normally want to use cd "$dir" instead of letting the shell word-split the expansion of "$dir". Surprised that didn't consume the r characters.
– Peter Cordes
Sep 2 at 16:23

You'd normally want to use cd "$dir" instead of letting the shell word-split the expansion of "$dir". Surprised that didn't consume the r characters.
– Peter Cordes
Sep 2 at 16:23

2

2

@PeterCordes, the carriage return isn't contained in the default IFS (and it's not "IFS white space"), so it acts like any character, just invisible.
– ilkkachu
Sep 2 at 16:57

@PeterCordes, the carriage return isn't contained in the default IFS (and it's not "IFS white space"), so it acts like any character, just invisible.
– ilkkachu
Sep 2 at 16:57

1

1

Using cd in a script file and executing that script as a command (just specifying its name e.g. ./test.sh) won't do what you expect - the script runs in a subprocess, and the directory will be changed in that process, but not in your interactive shell. Using ". test.sh" uses the "." shell command to have your current interactive shell run the commands in the script, which will change the directory as you're expecting. (NOTE: this is how it works in Linux, things may be different in WSL.)
– Randy Orrison
Sep 3 at 7:39

Using cd in a script file and executing that script as a command (just specifying its name e.g. ./test.sh) won't do what you expect - the script runs in a subprocess, and the directory will be changed in that process, but not in your interactive shell. Using ". test.sh" uses the "." shell command to have your current interactive shell run the commands in the script, which will change the directory as you're expecting. (NOTE: this is how it works in Linux, things may be different in WSL.)
– Randy Orrison
Sep 3 at 7:39

add a comment | 

2 Answers
2

active

oldest

votes

up vote
17
down vote



accepted

It's because you have created your script in a windows machine, some r (carriage return) has been added at the end of each line.

Remove them like this:

tr -d 'r' < test.sh > new-test.sh

Also quote the variable's value:

cd "$dir"

then run your script:

./new-test.sh

As a hint it's also better to use:

 cd ... || exit

in case of any failure.

---

Configure your editor so it uses Linux format for saving files (If it's capable of) or use an editor in bash like nano:

share|improve this answer

edited Sep 3 at 9:36

terdon♦

61.9k12127205

answered Sep 2 at 15:29

Ravexina

27.3k146594

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  dir=foo is basically safe, unless it contains literal whitespace. glob expansion doesn't happen on variable assignments. Where you really should use quoting is on cd "$dir". (Also, I just checked, and foo="abc"r (carriage-return typed using control-v control-m in bash) still includes the CR in the value of foo, according to echo "$foo" | hexdump -C. So quoting doesn't protect variable definitions from trailing CRs on future edits, and also r isn't a whitespace character for word-splitting.)
  – Peter Cordes
  Sep 2 at 16:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @PeterCordes The quoting was a general advice not relating to r at all... but thank you for clarification :)
  – Ravexina
  Sep 2 at 16:32
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yeah, I would normally quote variable definitions just because there's no reason not to. It's less necessary than in most other contexts, though, because glob expansion doesn't happen, only word splitting. But yeah, always quote unless you specifically want some kind of expansion somewhere.
  – Peter Cordes
  Sep 2 at 16:34
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @PeterCordes, word splitting doesn't happen in variable assignments. That is, if a contains foo bar, then b=$a also assigns foo bar to b. Of course if you do b="foo bar", you need the quotes, but that's just how the shell parses the input, and isn't the same as word splitting.
  – ilkkachu
  Sep 2 at 16:59
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  It would even be better to have cd -- "$dir", in case the directory changed name to something like -L
  – ace
  Sep 3 at 5:12
  

  
  
  
  

 | 
show 2 more comments

up vote
11
down vote

Another option is to using dos2unix command to convert the file to Unix type format.

Usage:

dos2unix your_file

share|improve this answer

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

add a comment | 

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
17
down vote



accepted

It's because you have created your script in a windows machine, some r (carriage return) has been added at the end of each line.

Remove them like this:

tr -d 'r' < test.sh > new-test.sh

Also quote the variable's value:

cd "$dir"

then run your script:

./new-test.sh

As a hint it's also better to use:

 cd ... || exit

in case of any failure.

---

Configure your editor so it uses Linux format for saving files (If it's capable of) or use an editor in bash like nano:

share|improve this answer

edited Sep 3 at 9:36

terdon♦

61.9k12127205

answered Sep 2 at 15:29

Ravexina

27.3k146594

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  dir=foo is basically safe, unless it contains literal whitespace. glob expansion doesn't happen on variable assignments. Where you really should use quoting is on cd "$dir". (Also, I just checked, and foo="abc"r (carriage-return typed using control-v control-m in bash) still includes the CR in the value of foo, according to echo "$foo" | hexdump -C. So quoting doesn't protect variable definitions from trailing CRs on future edits, and also r isn't a whitespace character for word-splitting.)
  – Peter Cordes
  Sep 2 at 16:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @PeterCordes The quoting was a general advice not relating to r at all... but thank you for clarification :)
  – Ravexina
  Sep 2 at 16:32
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yeah, I would normally quote variable definitions just because there's no reason not to. It's less necessary than in most other contexts, though, because glob expansion doesn't happen, only word splitting. But yeah, always quote unless you specifically want some kind of expansion somewhere.
  – Peter Cordes
  Sep 2 at 16:34
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @PeterCordes, word splitting doesn't happen in variable assignments. That is, if a contains foo bar, then b=$a also assigns foo bar to b. Of course if you do b="foo bar", you need the quotes, but that's just how the shell parses the input, and isn't the same as word splitting.
  – ilkkachu
  Sep 2 at 16:59
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  It would even be better to have cd -- "$dir", in case the directory changed name to something like -L
  – ace
  Sep 3 at 5:12
  

  
  
  
  

 | 
show 2 more comments

up vote
17
down vote



accepted

It's because you have created your script in a windows machine, some r (carriage return) has been added at the end of each line.

Remove them like this:

tr -d 'r' < test.sh > new-test.sh

Also quote the variable's value:

cd "$dir"

then run your script:

./new-test.sh

As a hint it's also better to use:

 cd ... || exit

in case of any failure.

---

Configure your editor so it uses Linux format for saving files (If it's capable of) or use an editor in bash like nano:

share|improve this answer

edited Sep 3 at 9:36

terdon♦

61.9k12127205

answered Sep 2 at 15:29

Ravexina

27.3k146594

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  dir=foo is basically safe, unless it contains literal whitespace. glob expansion doesn't happen on variable assignments. Where you really should use quoting is on cd "$dir". (Also, I just checked, and foo="abc"r (carriage-return typed using control-v control-m in bash) still includes the CR in the value of foo, according to echo "$foo" | hexdump -C. So quoting doesn't protect variable definitions from trailing CRs on future edits, and also r isn't a whitespace character for word-splitting.)
  – Peter Cordes
  Sep 2 at 16:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @PeterCordes The quoting was a general advice not relating to r at all... but thank you for clarification :)
  – Ravexina
  Sep 2 at 16:32
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yeah, I would normally quote variable definitions just because there's no reason not to. It's less necessary than in most other contexts, though, because glob expansion doesn't happen, only word splitting. But yeah, always quote unless you specifically want some kind of expansion somewhere.
  – Peter Cordes
  Sep 2 at 16:34
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @PeterCordes, word splitting doesn't happen in variable assignments. That is, if a contains foo bar, then b=$a also assigns foo bar to b. Of course if you do b="foo bar", you need the quotes, but that's just how the shell parses the input, and isn't the same as word splitting.
  – ilkkachu
  Sep 2 at 16:59
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  It would even be better to have cd -- "$dir", in case the directory changed name to something like -L
  – ace
  Sep 3 at 5:12
  

  
  
  
  

 | 
show 2 more comments

up vote
17
down vote



accepted

up vote
17
down vote



accepted

It's because you have created your script in a windows machine, some r (carriage return) has been added at the end of each line.

Remove them like this:

tr -d 'r' < test.sh > new-test.sh

Also quote the variable's value:

cd "$dir"

then run your script:

./new-test.sh

As a hint it's also better to use:

 cd ... || exit

in case of any failure.

---

Configure your editor so it uses Linux format for saving files (If it's capable of) or use an editor in bash like nano:

share|improve this answer

edited Sep 3 at 9:36

terdon♦

61.9k12127205

answered Sep 2 at 15:29

Ravexina

27.3k146594

It's because you have created your script in a windows machine, some r (carriage return) has been added at the end of each line.

Remove them like this:

tr -d 'r' < test.sh > new-test.sh

Also quote the variable's value:

cd "$dir"

then run your script:

./new-test.sh

As a hint it's also better to use:

 cd ... || exit

in case of any failure.

---

Configure your editor so it uses Linux format for saving files (If it's capable of) or use an editor in bash like nano:

share|improve this answer

edited Sep 3 at 9:36

terdon♦

61.9k12127205

answered Sep 2 at 15:29

Ravexina

27.3k146594

share|improve this answer

share|improve this answer

edited Sep 3 at 9:36

terdon♦

61.9k12127205

edited Sep 3 at 9:36

terdon♦

61.9k12127205

edited Sep 3 at 9:36

terdon♦

61.9k12127205

61.9k12127205

answered Sep 2 at 15:29

Ravexina

27.3k146594

answered Sep 2 at 15:29

Ravexina

27.3k146594

answered Sep 2 at 15:29

Ravexina

27.3k146594

27.3k146594

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  dir=foo is basically safe, unless it contains literal whitespace. glob expansion doesn't happen on variable assignments. Where you really should use quoting is on cd "$dir". (Also, I just checked, and foo="abc"r (carriage-return typed using control-v control-m in bash) still includes the CR in the value of foo, according to echo "$foo" | hexdump -C. So quoting doesn't protect variable definitions from trailing CRs on future edits, and also r isn't a whitespace character for word-splitting.)
  – Peter Cordes
  Sep 2 at 16:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @PeterCordes The quoting was a general advice not relating to r at all... but thank you for clarification :)
  – Ravexina
  Sep 2 at 16:32
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yeah, I would normally quote variable definitions just because there's no reason not to. It's less necessary than in most other contexts, though, because glob expansion doesn't happen, only word splitting. But yeah, always quote unless you specifically want some kind of expansion somewhere.
  – Peter Cordes
  Sep 2 at 16:34
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @PeterCordes, word splitting doesn't happen in variable assignments. That is, if a contains foo bar, then b=$a also assigns foo bar to b. Of course if you do b="foo bar", you need the quotes, but that's just how the shell parses the input, and isn't the same as word splitting.
  – ilkkachu
  Sep 2 at 16:59
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  It would even be better to have cd -- "$dir", in case the directory changed name to something like -L
  – ace
  Sep 3 at 5:12
  

  
  
  
  

 | 
show 2 more comments

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  dir=foo is basically safe, unless it contains literal whitespace. glob expansion doesn't happen on variable assignments. Where you really should use quoting is on cd "$dir". (Also, I just checked, and foo="abc"r (carriage-return typed using control-v control-m in bash) still includes the CR in the value of foo, according to echo "$foo" | hexdump -C. So quoting doesn't protect variable definitions from trailing CRs on future edits, and also r isn't a whitespace character for word-splitting.)
  – Peter Cordes
  Sep 2 at 16:29
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @PeterCordes The quoting was a general advice not relating to r at all... but thank you for clarification :)
  – Ravexina
  Sep 2 at 16:32
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yeah, I would normally quote variable definitions just because there's no reason not to. It's less necessary than in most other contexts, though, because glob expansion doesn't happen, only word splitting. But yeah, always quote unless you specifically want some kind of expansion somewhere.
  – Peter Cordes
  Sep 2 at 16:34
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @PeterCordes, word splitting doesn't happen in variable assignments. That is, if a contains foo bar, then b=$a also assigns foo bar to b. Of course if you do b="foo bar", you need the quotes, but that's just how the shell parses the input, and isn't the same as word splitting.
  – ilkkachu
  Sep 2 at 16:59
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  It would even be better to have cd -- "$dir", in case the directory changed name to something like -L
  – ace
  Sep 3 at 5:12
  

  
  
  
  

2

2

dir=foo is basically safe, unless it contains literal whitespace. glob expansion doesn't happen on variable assignments. Where you really should use quoting is on cd "$dir". (Also, I just checked, and foo="abc"r (carriage-return typed using control-v control-m in bash) still includes the CR in the value of foo, according to echo "$foo" | hexdump -C. So quoting doesn't protect variable definitions from trailing CRs on future edits, and also r isn't a whitespace character for word-splitting.)
– Peter Cordes
Sep 2 at 16:29

dir=foo is basically safe, unless it contains literal whitespace. glob expansion doesn't happen on variable assignments. Where you really should use quoting is on cd "$dir". (Also, I just checked, and foo="abc"r (carriage-return typed using control-v control-m in bash) still includes the CR in the value of foo, according to echo "$foo" | hexdump -C. So quoting doesn't protect variable definitions from trailing CRs on future edits, and also r isn't a whitespace character for word-splitting.)
– Peter Cordes
Sep 2 at 16:29

@PeterCordes The quoting was a general advice not relating to r at all... but thank you for clarification :)
– Ravexina
Sep 2 at 16:32

@PeterCordes The quoting was a general advice not relating to r at all... but thank you for clarification :)
– Ravexina
Sep 2 at 16:32

Yeah, I would normally quote variable definitions just because there's no reason not to. It's less necessary than in most other contexts, though, because glob expansion doesn't happen, only word splitting. But yeah, always quote unless you specifically want some kind of expansion somewhere.
– Peter Cordes
Sep 2 at 16:34

Yeah, I would normally quote variable definitions just because there's no reason not to. It's less necessary than in most other contexts, though, because glob expansion doesn't happen, only word splitting. But yeah, always quote unless you specifically want some kind of expansion somewhere.
– Peter Cordes
Sep 2 at 16:34

1

1

@PeterCordes, word splitting doesn't happen in variable assignments. That is, if a contains foo bar, then b=$a also assigns foo bar to b. Of course if you do b="foo bar", you need the quotes, but that's just how the shell parses the input, and isn't the same as word splitting.
– ilkkachu
Sep 2 at 16:59

@PeterCordes, word splitting doesn't happen in variable assignments. That is, if a contains foo bar, then b=$a also assigns foo bar to b. Of course if you do b="foo bar", you need the quotes, but that's just how the shell parses the input, and isn't the same as word splitting.
– ilkkachu
Sep 2 at 16:59

It would even be better to have cd -- "$dir", in case the directory changed name to something like -L
– ace
Sep 3 at 5:12

It would even be better to have cd -- "$dir", in case the directory changed name to something like -L
– ace
Sep 3 at 5:12

 | 
show 2 more comments

up vote
11
down vote

Another option is to using dos2unix command to convert the file to Unix type format.

Usage:

dos2unix your_file

share|improve this answer

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

add a comment | 

up vote
11
down vote

Another option is to using dos2unix command to convert the file to Unix type format.

Usage:

dos2unix your_file

share|improve this answer

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

add a comment | 

up vote
11
down vote

up vote
11
down vote

Another option is to using dos2unix command to convert the file to Unix type format.

Usage:

dos2unix your_file

share|improve this answer

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

Another option is to using dos2unix command to convert the file to Unix type format.

Usage:

dos2unix your_file

share|improve this answer

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

share|improve this answer

share|improve this answer

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

answered Sep 2 at 16:52

αғsнιη

23.2k2191152

23.2k2191152

add a comment | 

add a comment |