#!/bin/bash
echo 'first line' >foo.xml
echo 'second line' >>foo.xml
I am a total newbie to shell scripting.
I am trying to run the above script in cygwin. I want to be able to write one line after the other to a new file.
However, when I execute the above script, I see the follwoing contents in foo.xml:
second line
The second time I run the script, I see in foo.xml:
second line
second line
and so on.
Also, I see the following error displayed at the command prompt after running the script:
: No such file or directory.xml
I will eventually be running this script on a unix box, I am just trying to develop it using cygwin. So I would appreciate it if you could point out if it is a cygwin oddity and if so, should I avoid trying to use cygwin for development of such scripts?
Thanks in advance.
Run dos2unix on your shell script. That will fix the problem.
I had the same kind of problem as the original poster: A very simple script file was not working in Cygwin.
Thanks to Don Branson for the clue.
The fix for me was built into the text editor I'm using. (Most programmer's editors have a feature like this.) For example, in my case I'm using Notepad++, which has a menu item to convert the file line endings to Unix-style. From the menu: [Edit]->[EOL Conversion]->[Unix (LF)]
Then the script behaved as expected.
But there must be something else that is wrong here. When I try it, it works as expected.
> foo.xml puts the line into foo.xml, replacing any previous contents.
>> foo.xml appends to file
It sounds like you may have a typo somewhere. Also keep in mind that while the Windows command prompt can be forgiving about paths with embedded spaces, cygwin's shells will not be, so if you have a filename that contains embedded spaces, you need to either quote the filename or escape the spaces:
echo 'first line' > 'My File.txt'
echo 'first line' > My\ File.txt
The same goes for certain "special" characters including quotes, ampersand (&), semicolons (;) and generally most punctuation other than period/full-stop (.).
So if you are seeing those issues using the exact script that you are running (i.e. you copy and pasted it, there is no possibility of transcription errors) then something truly strange may be happening that I can't explain. Otherwise, there may be a misplaced space or unquoted character somewhere.
I cannot reproduce your results. The script you quote looks correct, and indeed works as expected in my installation of Cygwin here, producing the file foo.xml containing the lines first line and second line; implying that what you are actually running differs from what you quoted in some way that is causing the problem.
The error message implies some sort of problem with the filename in the first echo line. Do you have some nonprintable characters in the script you are running? Have you missed escaping a space in the filename? Are you subsituting shell variables and mistyping the name of the variable or failing to escape the resulting string?
The above should work normally..
However you can always specify a heredoc:
#!/bin/bash
cat <<EOF > foo.xml
first line
second line
EOF
Related
I am having trouble trying to add environment variables to a REnviron file that have special characters. This is on a Debian machine with the file located at /usr/lib/R/etc/Renviron. If my value has a &, I get a weird error when installing packages (although the package installs fine):
REnviron file: TEST_KEY=HEY&X&THERE
Command: install.packages(futures)
Error:
/usr/lib/R/bin/Rcmd: 468: /usr/lib/R/etc/Renviron: THERE: not found
/usr/lib/R/bin/Rcmd: 468: /usr/lib/R/etc/Renviron: X: not found
Which seems like it's because & is a special character. I can fix this by putting quotes around the value like this: TEST_KEY="HEY&X&THERE". However at that point I can't figure out how to handle when a value itself has a " in it. For example if I wanted the value to be HEY&"&THERE I am not sure how to format that (a backlash in front of the quote didn't work). I tried "HEY&\"&THERE", but that left the \ in the string once loaded into R. Which leads me to my broader question:
How can I ensure that anything that satisfies linux environment variable styling rules works in an REnviron file?
Update: this seems to be a Debian specific issue. You can recreate it using the debian:bullseye-slim docker image, installing R, then editing the Renviron to have a & in it.
Okay I spent an hour looking into this and I think there is the answer.
In both Ubuntu and Debian (and maybe other systems too), the Renviron file gets executed within bash. So what you're typing in the file is exactly bash commands. You can see in lines 39-40 of RCmd the commands:
. "${R_HOME}/etc${R_ARCH}/Renviron"
export `sed 's/^ *#.*//; s/^\([^=]*\)=.*/\1/' "${R_HOME}/etc${R_ARCH}/Renviron"`
The first line runs the Renviron file in the shell, the second then exports the variable names based on lines that have a = in them.
So in our case the way to handle this is to put double quotations around all the values, and any double-quote within the string should get a \ before it. The reason why I didn't realize the solution before I posted the question is that I didn't use cat() when printing my text in R, which removes the leading \. So: "HEY&\"&THERE" would be the right way to do it.
To recap:
The Renviron file is executed on the shell
To handle special characters in strings you use the same logic you would in the OS (so double quotes with \ to escape actual double quotes).
I'm trying to execute a R script which has spaces in the path leading to it. It fails with path not found error. My command looks like this..
Rscript ../A/B C/test.R
I've tried
Rscript "`../A/B C/test.R`"
Rscript "../A/B C/test.R"
Doesn't work. What's going wrong here?
First let's try the obvious, escape the space:
Rscript "../A/B\ C/test.R"
If that doesn't work, cd inside the folder and try calling it from there:
cd A/B\ C/ && Rscript test.r
(Assuming you're in the parent folder)
If is still not working.. maybe is something inside the script.. What do you have in it?
R has problem sometimes managing spaces with single escape characters, so, if -let's say-, inside your script you have:
source("x.r")
And the FULL PATH of x.r has spaces in its name (like being in the same folder as the file in your example..), it can fail due to not finding the file called from inside r.
Then, change the paths INSIDE the script to have double escapes at the spaces
/A/B C/ -> /A/B\\ C/
And try again the previous options i posted.
Tell us what happens!
Make sure you are running your line of code from the Unix shell.
There may be an error in your directory name or file itself. As a test case, you may try the following:
Rscript "/directory/test A/rnorm.R"
rnorm.R being:
x <- rnorm(200, 10, 4)
print(x)
This basically should print the numbers to your Shell.
As I'm learning more about UNIX commands I started working with sed at work. Sed's design reads a file in line by line, and executes commands on each line individually.
How does grep process files? I've tried various ways of googling "does grep process line by line" and nothing really concrete shows up.
From Why GNU grep is fast :
Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking for newlines would slow grep down by a factor of several times, because to find the newlines it would have to look at every byte!
and then
Don't look for newlines in the input until after you've found a match.
EDIT:
I will correct myself. It is neither line by line nor full file, its in terms of chunks of data which are placed into the buffer.
More details are here http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
The regular expression you pass to grep doesn't have any way of specifying newlines (although you can specify matches against the start or end of a line).
So it appears to work line by line, even though actually it may not treat line ends differently to other characters.
I am taking a intro to Unix class and am stuck on the final assignment. I need to write a script to change the file extension of a filename that is input when the script is run. The new file extension is also input when the script is run. The script is call chExt1.sh . Our first trial of the script is run as follows
./chExt1.sh cpp aardvark.CPP
The script is suppose to change the second input file extension to the file extension given in the first input. It is not suppose to matter what file extension is given with the file name or what file extension is given as the new extension, nor is it only for changing uppercase to lowercase. In hope to make this very clear if given the following:
./chExt1.sh istink helpme.plEaSe
The script would change helpme.plEaSe to helpme.istink . I have searched on this forum and in google and have had no look with trying the different examples I found. Below is some of the examples I have tried and what I currently have.
Current
#!/bin/sh
fileExtension="$1"
shift
oldName="$2"
shift
newName=${oldName%%.*}${fileExtension}
echo $newName
The echo is just to see if it works, and if I get it working I'm going to add an mv to save it.
Others that I have tried:
newName=`${oldName%.*}`
newName=`${oldName#.*}`
sed 's/\.*//' $oldName > $newName
I can't seem to find some of the other sed I have used but they involved alot of backslashes and () with .* in there. I did not try the basename command cause I don't know the file extension to be entered and all I the examples I saw required that you specify what you wanted removed and I can't. I did not list all the different quote variations that I used but I have tried alot. My instructions say to use the sed command since we should know how to use that from class but when I try to do it I don't isolate just the ending of the file and I believe (cause it takes so long to finish) that it is going through the whole file and looking for .'s and anything after cause I kept doing .* as the pattern. Thanks for anyhelp you can give.
shift shifts the positional parameters, so after calling shift the second parameter ($2) is now the first ($1). The second shift is not necessary, because you are done accessing the parameters. You need to either remove the shift
#!/bin/sh
fileExtension="$1"
oldName="$2"
newName=${oldName%%.*}${fileExtension}
echo $newName
or change $2 to $1.
#!/bin/sh
fileExtension="$1"
shift
oldName="$1"
newName=${oldName%%.*}${fileExtension}
echo $newName
However, you are still missing a dot from your new file name. That is left as an exercise for the reader.
I am using Gina Trapiani's excellent todo.sh to organize my todo-list.
However being a dane, it would be nice if the script accepted special danish characters like ø and æ.
I am an absolute UNIX-n00b, so it would be a great help if anybody could tell me how to fix this! :)
Slowly, the Unix world is moving from ASCII and other regional encodings to UTF-8. You need to be running a UTF terminal, such as a modern xterm or putty.
In your ~/.bash_profile set you language to be one of the UTF-8 variants.
export LANG=C.UTF-8
or
export LANG=en_AU.UTF-8
etc..
You should then be able to write UTF-8 characters in the terminal, and include them in bash scripts.
#!/bin/bash
echo "UTF-8 is græat ☺"
See also: https://serverfault.com/questions/11015/utf-8-and-shell-scripts
What does this command show?
locale
It should show something like this for you:
LC_CTYPE="da_DK.UTF-8"
LC_NUMERIC="da_DK.UTF-8"
LC_TIME="da_DK.UTF-8"
LC_COLLATE="da_DK.UTF-8"
LC_MONETARY="da_DK.UTF-8"
LC_MESSAGES="da_DK.UTF-8"
LC_PAPER="da_DK.UTF-8"
LC_NAME="da_DK.UTF-8"
LC_ADDRESS="da_DK.UTF-8"
LC_TELEPHONE="da_DK.UTF-8"
LC_MEASUREMENT="da_DK.UTF-8"
LC_IDENTIFICATION="da_DK.UTF-8"
LC_ALL=
If not, you might try doing this before you run your script:
LANG=da_DK.UTF-8
You don't say what happens when you run the script and it encounters these characters. Are they in the todo file? Are they entered at a prompt? Is there an error message? Is something output in place of the expected output?
Try this and see what you get:
read -p "Enter some characters" string
echo "$string"