If I run this script:
#!/bin/bash
HOSTNAME=$(< ds.tmp)
echo "Hello${HOSTNAME}!"
TEST="1.2.3.4"
echo "Hello${TEST}!"
With the contents of ds.tmp only an ip address (say 1.2.3.4), the result is:
!ello1.2.3.4
Hello1.2.3.4!
So after I print a variable that is assigned by a $(...), the cursor position is reset and it overwrites all text.
Why is this? I have looked everywhere but cannot find a reference this anywhere...
Your ds.tmp file has CR-LF as its line breaks. As a result, ${HOSTNAME} contains 1.2.3.4\r, not just 1.2.3.4.
Unix text files should just use LF as their line breaks. Use dos2unix to fix it.
Try this:
HOSTNAME=$(tr -d "\r" < ds.tmp)
Related
i want to make a start.config file by using bat script.
I want to add to my config file that parameter:
StartAgents=9
WITHOUT space at the end of line.
Unfortunately command:
echo StartAgents=9>>C:\start.config
not working, I think that there is "collision" with two characters: "9>"
Command:
echo StartAgents=9 >>C:\start.config
is working, but this is adding space at the end of line in my config file - i dont want that.
Any ideas how to do that?
I want to add line StartAgents=9 without space af the end of line.
want:
StartAgents=9
dont want:
StartAgents=9
You have to escape the number, so that it isn't interpreted by CMD.EXE as a file descriptor number.
Then you can add the >> redirection directly after the number to not insert a trailing space.
Example:
echo StartAgent=^9>>test.txt
Related Information:
Omitting trailing space
File Descriptor Usage
I have a .env file with the following:
FST_TEST=1
SCD_TEST=2
I run source .env and then:
If I run echo "$FST_TEST$FST_TEST" it prints 1.
If I run echo "$SCD_TEST$SCD_TEST" it prints 22.
I would have expected echo "$FST_TEST$FST_TEST" to also prints 11 but I can't manage to do it... I think there is something with the Return character.
Most likely, it's because .env file is in Windows/DOS format.
Can you do :
dos2unix .env
With DOS end of line, FST_TEST=1, is actually FST_TEST=1\r.
\r makes the cursor go to beginning of the line, so the 1
you saw is two 1s, one on top the other.
On the second line, you didn't put end of line, so there was no problem.
Not sure what does your .env file contains. Can you send its content??
Maybe try this:
echo ${FST_TEST}${FST_TEST}
Hope it helps.
I am trying to delete a set of lines from a file by passing variables.
Below is my file :
$ cat checking.txt
Starting1
DELETE /*+NESTED_TABLE_SET_REFS+*/ FROM tables1
Ending1
Starting2
update table
set col1=2
where val2=685
Ending2
Starting3
update table
set col1=1
where val1=44
Ending3
so in above files I need to delete lines from 1st line to 4th line.
I used below command and it was working fine.
sed '1,4d' checking.txt
Now I gave variable a a value, like a=4
echo $a
4
Now I tried the sed command like
sed "1,${a}d" checking.txt
sed: 0602-404 Function 1, 4d cannot be parsed.
Can someone please tell me how to pass variable here?
Thanks in Advance
One way you could attempt this problem is in the following way. Assuming you want to delete lines between start and stop, you could write
awk '(NR<start) || (stop<NR)' start=1 stop=4 file
The way you are proposing it to work also works,
start=1
stop=4
sed "${start},${stop}d" file
The reason why it failed in your case is because the variable a seems to have blanks in front of it. You notice this from the errormessage and the blanks space in front of the 4.
I am trying to get variables into a block of text which will later be echoed to a file.
Problem is the $VAR is not getting converted into the variable's value ??
VAR="SOME Value"
read -d '' WPA <<"BLOCK"
Description='WIFI'
Interface=wlan0
Connection=wireless
IP=dhcp
Security=wpa
Key=$VAR
BLOCK
echo "$WPA"
Also, is it possible to append further text to the WPA Block ?
When you quote the delimeter of a heredoc, variables are not interpolated. Just drop the quotes:
read -d '' WPA <<BLOCK
Description='WIFI'
Interface=wlan0
Connection=wireless
IP=dhcp
Security=wpa
Key=$VAR
BLOCK
Why don't you just say
WPA="Description='WIFI'
Interface=wlan0
Connection=wireless
IP=dhcp
Security=wpa
Key=$VAR
"
?
There's not really a need to use read in your case.
If you want to echo append text to $WPA, do it like this:
WPA="$WPA
first appended line
second appended line
"
but be aware that you insert an extra newline this way - $WPA had a newline at the end and there's another one at the beginning of the new text. To avoid this, use
WPA="${WPA}first appended line
second appended line
"
The {} quotation delimits the variable name. Using
WPA="$WPAfirst appended line
would look for a variable named WPAfirst.
is it possible to append further text to the WPA Block ?
$WPA is just a normal shell variable (that happens to contain a multi-line string), so you can append to it with +=; e.g.:
WPA+=$'\nanother line\nand another'
If you wanted to append the content of another heredoc, assign it to a separate variable and append that to WPA (but, as #GuntramBlohm points out, you can just as easily assign/append a multi-line string directly).
I would need to read certain data using curl. I'm basically reading keywords from file
while read line
do
curl 'https://gdata.youtube.com/feeds/api/users/'"${line}"'/subscriptions?v=2&alt=json' \
> '/home/user/archive/'"$line"
done < textfile.txt
Anyway I haven't found a way to form the url to curl so it would work. I've tried like every possible single and double quoted versions. I've tried basically:
'...'"$line"'...'
"..."${line}"..."
'...'$line'...'
and so on.. Just name it and I'm pretty sure that I've tried it.
When I'm printing out the URL in the best case it will be formed as:
/subscriptions?v=2&alt=jsoneeds/api/users/KEYWORD FROM FILE
or something similar. If you know what could be the cause of this I would appreciate the information. Thanks!
It's not a quoting issue. The problem is that your keyword file is in DOS format -- that is, each line ends with carriage return & linefeed (\r\n) rather than just linefeed (\n). The carriage return is getting read into the line variable, and included in the URL. The giveaway is that when you echo it, it appears to print:
/subscriptions?v=2&alt=jsoneeds/api/users/KEYWORD FROM FILE"
but it's really printing:
https://gdata.youtube.com/feeds/api/users/KEYWORD FROM FILE
/subscriptions?v=2&alt=json
...with just a carriage return between them, so the second overwrites the first.
So what can you do about it? Here's a fairly easy way to trim the cr at the end of the line:
cr=$'\r'
while read line
do
line="${line%$cr}"
curl "https://gdata.youtube.com/feeds/api/users/${line}/subscriptions?v=2&alt=json" \
> "/home/user/archive/$line"
done < textfile.txt
Your current version should work, I think. More elegant is to use a single pair of double quotes around the whole URL with the variable in ${}:
"https://gdata.youtube.com/feeds/api/users/${line}/subscriptions?v=2&alt=json"
Just use it like this, should be sufficient enough:
curl "https://gdata.youtube.com/feeds/api/users/${line}/subscriptions?v=2&alt=json" > "/home/user/archive/${line}"
If your shell gives you issues with & just put \&, but it works fine for me without it.
If the data from the file can contain spaces and you have no objection to spaces in the file name in the /home/user/archive directory, then what you've got should be OK.
Given the contents of the rest of the URL, you could even just write:
while read line
do
curl "https://gdata.youtube.com/feeds/api/users/${line}/subscriptions?v=2&alt=json" \
> "/home/user/archive/${line}"
done < textfile.txt
where strictly the ${line} could be just $line in both places. This works because the strings are fixed and don't contain shell metacharacters.
Since you're code is close to this, but you claim that you're seeing the keywords from the file in the wrong place, maybe a little rewriting for ease of debugging is in order:
while read line
do
url="https://gdata.youtube.com/feeds/api/users/${line}/subscriptions?v=2&alt=json"
file="/home/user/archive/${line}"
curl "$url" > "$file"
done < textfile.txt
Since the strings may end up containing spaces, it seems (do you need to expand spaces to + in the URL?), the quotes around the variables are strongly recommended. You can now run the script with sh -x (or add a line set -x to the script) and see what the shell thinks it is doing as it is doing it.