I have run into a bash variable string problem that I think I have nailed down to the variable string containing a tilde (~). Not sure if my conclusion is correct and could use some help.
To make a long(er) story short, an associative array variable was created:
p[work_path]="~/projects/test/"
and referenced in the following format in the shell script:
"${p[work_path]}"
To my consternation this worked fine in some places but not in others. I tried to use the above construct when piping output, as part of a file reference when calling psql from the command line and when referencing an xslt file with xsltproc.
In some places it worked, in others it did not but when I substituted the variable reference above with the path in clear text itself it then worked.
It looks like there are some nuances on variable substitution that I have yet to learn, perhaps tied to the use of the tilde since using the variable p[work_path]="/home/user/projects/test/" seemed to work in all places.
Pointers welcome!
On 7/6/22 18:41, H wrote:
To my consternation this worked fine in some places but not in others.
It might be easier to explain if you had an example of where it worked. The bash man page has a section titled "EXPANSION" that details the order in which expansions happen. Since tilde expansion happens before variable expansion, the case you're discussing shouldn't work in any context (other than an eval or equivalent).
On 07/06/2022 10:42 PM, Gordon Messmer wrote:
On 7/6/22 18:41, H wrote:
To my consternation this worked fine in some places but not in others.
It might be easier to explain if you had an example of where it worked. The bash man page has a section titled "EXPANSION" that details the order in which expansions happen. Since tilde expansion happens before variable expansion, the case you're discussing shouldn't work in any context (other than an eval or equivalent).
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Thank you, I read up on bash expansion of tilde and realized substituting $HOME for ~ would be the best. Once I had done that the script worked.
The reason it worked in some places may have been that I had set the script to POSIX compliant using:
set +o posix
On Wed, Jul 06, 2022 at 09:41:14PM -0400, H wrote:
I have run into a bash variable string problem that I think I have nailed down to the variable string containing a tilde (~). Not sure if my conclusion is correct and could use some help.
To make a long(er) story short, an associative array variable was created:
p[work_path]="~/projects/test/"
and referenced in the following format in the shell script:
"${p[work_path]}"
Is there a reason you desire "delayed" evaluation of the tilde?
If no, then evaluate the tilde in the above assignment by not quoting it.
If yes, then where tilde evaluation IS wanted, you will likely need to do a second round of shell evaluation of the command line by using the keyword "eval".
$ x="~/foo" $ y=~"/foo" # y contains the tilde evaluated version
$ echo "$x $y" ~/foo /home/jon/foo
$ echo $x $y # quotes don't matter here ~/foo /home/jon/foo
$ eval echo "$x $y" /home/jon/foo /home/jon/foo
Use of eval could introduce other unexpected/unwanted evaluations and is discouraged unless required.
On 07/07/2022 12:52 AM, Jon LaBadie wrote:
On Wed, Jul 06, 2022 at 09:41:14PM -0400, H wrote:
I have run into a bash variable string problem that I think I have nailed down to the variable string containing a tilde (~). Not sure if my conclusion is correct and could use some help.
To make a long(er) story short, an associative array variable was created:
p[work_path]="~/projects/test/"
and referenced in the following format in the shell script:
"${p[work_path]}"
Is there a reason you desire "delayed" evaluation of the tilde?
If no, then evaluate the tilde in the above assignment by not quoting it.
If yes, then where tilde evaluation IS wanted, you will likely need to do a second round of shell evaluation of the command line by using the keyword "eval".
$ x="~/foo" $ y=~"/foo" # y contains the tilde evaluated version
$ echo "$x $y" ~/foo /home/jon/foo
$ echo $x $y # quotes don't matter here ~/foo /home/jon/foo
$ eval echo "$x $y" /home/jon/foo /home/jon/foo
Use of eval could introduce other unexpected/unwanted evaluations and is discouraged unless required.
Thank you, I read up on bash expansion of tilde and realized substituting $HOME for ~ would be the best and would avoid any other unforeseen complications.
Once I had done that the script worked.
Instead of using the ‘~’ in the file path, try using the ‘${HOME}’ variable instead. If you must use the ‘~’, you will likely need to escape it in many places. Another thing to note, if you use single quotes ( ‘ ) instead of double quotes ( “ ) , most places in bash scripts won’t try to expand the variables inside them. This is also helpful if you have a script calling SSH and want to pass a command to the remote server which contains a remote variable reference:
[bob@localhost bob]# ssh user@host ‘echo ${HOME}; exit’ [bob@localhost bob]# /home/user Vs: [bob@localhost bob]# ssh user@host “echo ${HOME}; exit” [bob@localhost bob]# /home/bob
Greg
From: CentOS centos-bounces@centos.org on behalf of H agents@meddatainc.com Date: Wednesday, July 6, 2022 at 21:41 To: Centos Mailing List centos@centos.org Subject: [CentOS] Special characters in bash strings [EXTERNAL] This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I have run into a bash variable string problem that I think I have nailed down to the variable string containing a tilde (~). Not sure if my conclusion is correct and could use some help.
To make a long(er) story short, an associative array variable was created:
p[work_path]="~/projects/test/"
and referenced in the following format in the shell script:
"${p[work_path]}"
To my consternation this worked fine in some places but not in others. I tried to use the above construct when piping output, as part of a file reference when calling psql from the command line and when referencing an xslt file with xsltproc.
In some places it worked, in others it did not but when I substituted the variable reference above with the path in clear text itself it then worked.
It looks like there are some nuances on variable substitution that I have yet to learn, perhaps tied to the use of the tilde since using the variable p[work_path]="/home/user/projects/test/" seemed to work in all places.
Pointers welcome!
_______________________________________________ CentOS mailing list CentOS@centos.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cent...