Special parameter $_ expands to a relative path
Hello, The Bash Reference Manual (http://www.gnu.org/s/bash/manual/bash.html#Special-Parameters) says: At shell startup, [$_ is] set to the absolute pathname used to invoke the shell or shell script being executed as passed in the environment or argument list. [...] However, with GNU bash, version 3.2.39 a simple script (named 'a'): #!/bin/bash echo "$_" prints './a' when invoked as './a'. According to the above excerpt, should it not print an absolute path to 'a' instead? Regards, Angel Tsankov
Re: Special parameter $_ expands to a relative path
On 09/01/11 15:11, Greg Wooledge wrote: On Thu, Sep 01, 2011 at 01:15:34AM -0800, Roger wrote: [...] The original poster may be interested in this page: http://mywiki.wooledge.org/BashFAQ/028 -- How do I determine the location of my script? I want to read some config files from the same place. That sounds like what he was hoping to accomplish. He is going to be disappointed, unless he's willing to accept one of the "90% solutions" that are so incredibly popular. Thanks for your answer! As I'm not inclined to accept less than 100% of anything, I'm indeed very unhappy with this situation. It turns out that a universal solution is to design shell scripts so that they never need to know their location. This, in turn, may lead to design restrictions in other parts of a system based at least partly on shell scripts. And this, at times, is certainly a pain in the ass. Regards, Angel Tsankov
No tilde expansion right after a quotation
Hi, Using bash 3.2.48(1)-release, echo ""~root prints ~root instead of /root. Is this the expected behaviour? Angel Tsankov
Re: No tilde expansion right after a quotation
Chet Ramey wrote:
> Angel Tsankov wrote:
>> Hi,
>>
>> Using bash 3.2.48(1)-release, echo ""~root prints ~root instead of
>> /root. Is this the expected behaviour?
>
> Yes. The tilde is not the first character in the word. Portions of
> words to be tilde-expanded can't be quoted at all, either.
I see. I came to this example from a real-world problem and, in case
someone can help, here it is. I'd like to append a path to CPATH
(separating it from the current contents of CPATH with a colon only if CPATH
is set and is not empty). The path-to-append points under usr1's home
directory. Also this should work in contexts such as CPATH=... . I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
expansions just to be on the safe side, though I think home directories may
not contain spaces.) Of course, this did not work for the reason pointed
above. However, removing the quotes still does not make the
tilde-expression to expand. How can I achieve my goal?
Regards,
Angel Tsankov
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> There may be other ways to do this, but:
>
> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>
> should work.
Well, I'd like to avoid the use of external commands.
--Angel
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> On Mon, Feb 16, 2009 at 9:26 AM, Angel Tsankov
> wrote:
>> Jon Seymour wrote:
>>> There may be other ways to do this, but:
>>>
>>> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>>>
>>> should work.
>>
>> Well, I'd like to avoid the use of external commands.
>>
>
> echo is a builtin, so if you are worried about performance costs
> associated with its execution, you shouldn't be.
In fact, I'm more concerned that in the expression:
CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)" some-command
I have no way to check echo's exit status. While it is probably true that
echo will hardly ever fail, I just want to make sure my script works as I
expect it to. This means handling every possible error.
-Angel
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> If you are willing to trade conciseness in order to eliminate use of
> builtin commands, you can use.
>
> local tmp=~usr1/blah/blah
> CPATH="${CPATH}${CPATH:+:}${tmp}"
>
> However, if you are concerned about echo failing, then you also need
> to be concerned about local failing.
>
> Hence:
>
> local tmp=~usr1/blah/bah
> [ $? -eq 0 ] || ... do something
> CPATH="${CPATH}${CPATH:+:}${tmp}"
>
> However, that is taking defensive programming to absurd levels.
>
> If the builtin echo fails it will be because the bash interpreter has
> suffered a catastrophic failure of some kind [ e.g. run out of memory
> ]. Once that has happened, all bets are off anyway.
>
> To be honest, it seems to me that your reluctance to use $(echo
> ~usr1/blah/blah) is rooted in an aesthetic objection or perhaps a lack
> of familiarity with the command substitution idiom. If the latter, I'd
> encourage you to reconsider, since command substitution is one of
> bash's most powerful features.
>
> [ Of course, others more experienced with bash idioms may object to
> $(echo ~usr1/blah/blah) on aesthetic grounds too - I welcome any
> suggested improvement!. ]
>
> jon.
Thanks for your replies,
Angel Tsankov
Re: No tilde expansion right after a quotation
Paul Jarc wrote:
> Jon Seymour wrote:
>> If the builtin echo fails it will be because the bash interpreter has
>> suffered a catastrophic failure of some kind [ e.g. run out of memory
>> ]. Once that has happened, all bets are off anyway.
>
> Probably true, but command substitution forks a separate process, so
> that can fail for reasons external to the bash process.
If process creation fails will $? will be set accordingly :-)
> Here's another possibility:
> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
That's clever!
-Angel
Re: No tilde expansion right after a quotation
Jon Seymour wrote:
> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>> Jon Seymour wrote:
>>> If the builtin echo fails it will be because the bash interpreter
>>> has suffered a catastrophic failure of some kind [ e.g. run out of
>>> memory ]. Once that has happened, all bets are off anyway.
>>
>> Probably true, but command substitution forks a separate process, so
>> that can fail for reasons external to the bash process.
>>
>> Here's another possibility:
>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>>
>
> Paul,
>
> Out of interest, how does one derive that outcome from the documented
> behaviour of bash? That is, which expansion rules are being invoked?
${#+~usr1/blah/blah} probably refers to $#. Strangely, this variable seems
to be defined even when not executing any function. However, in this case
"echo $#" prints "$#"! The expansion rules are exactly two:
${parameter:+word}
(http://www.gnu.org/software/bash/manual/bashref.html#Shell-Parameters,
3.5.3 Shell Parameter Expansion) and ${parameter} (3.5.3 Shell Parameter
Expansion)
-Angel
Re: No tilde expansion right after a quotation
Paul Jarc wrote:
> Jon Seymour wrote:
>> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>>
>> Out of interest, how does one derive that outcome from the documented
>> behaviour of bash? That is, which expansion rules are being invoked?
>
> It's ${parameter+word}, using $# (which is always set) as the
> parameter.
How do you know that $# is always set? And what about $...@? To what values
are these parameters set outside any function?
A more appropriate parameter to use could be $? which, by pure logic, seems
to be at least as often set as is $#.
-Angel
Re: No tilde expansion right after a quotation
Eric Blake wrote:
> According to Angel Tsankov on 2/15/2009 3:02 PM:
>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>> expansions just to be on the safe side, though I think home
>> directories may not contain spaces.)
>
> There are some contexts, such as variable assignments, where double
> quotes are not necessary.
>
> foo='a b'
> bar=$foo
>
> is just as safe as
>
> bar="$foo"
>
> In fact, it is MORE portable to avoid double quotes in assignments,
> if you are worried about writing scripts portable to more than just
> bash. Of these two constructs:
>
> foo="`echo "a b"`"
> bar=`echo "a b"`
>
> only the setting of bar is guaranteed to parse correctly in all
> shells.
Eric, thanks for youy replay. If double quotes are not that portable, then
how am I suppose to assign the output from some command to a variable when
the output contains a space?
-Angel
Re: No tilde expansion right after a quotation
Dave B wrote: > Angel Tsankov wrote: >> Eric, thanks for youy replay. If double quotes are not that >> portable, then how am I suppose to assign the output from some >> command to a variable when the output contains a space? > > Word splitting doesn't happen on assignments, so: > > $ var=$(echo "foo bar baz") > $ echo "$var" > foo bar baz Hmm, thanks for pointing this out. -Angel
Passing paths with spaces from one command to another
Hello, I want to pass the output from one command (e.g. find) to some other command so that each path (output by the first command) gets into a distinct positional parameter of the second command. How can I do this if some paths contain spaces?
Re: Passing paths with spaces from one command to another
What if the second command is a function defiend in a shell script, or a bash built-in command?
IFS valid characters
Hi, What are the valid charactes for the IFS variable? In particular, is '\0' a valid one?
Program to search unusual strings?
Hi, Which program can be used to search for line-feed characters in a string that might contain null characters? Regards, Angel Tsankov
Creating directories with sticky bit set
Hello, What can I do so that every directory I create has the sticky bit set? Regards, Angel Tsankov
Re: Creating directories with sticky bit set
Greg Wooledge wrote:
> If you only ever create directories from interactive shells with
> the "mkdir" command, you could override it with a function:
>
> mkdir() {
> command mkdir "$@" &&
> chmod +t "$@"
> }
>
> (In reality you'd want to process function arguments, and remove for
> example a "-p" option before passing them along to chmod. I'll leave
> that part as an exercise.)
>
Let's say that removing '-p' is straightforward, but what about setting the
sticky bit to every newly created directory component?
Regards,
Angel Tsankov
Testing standard output and exit statuses from commands in a pipe
Hello! I'd like to pipe the output from a command, say A, to another command, say B, then check if both commands completed successfully (i.e.with exist status 0) and, if so, compare the standard output from command B to some string. How can I do this in a bash script? Regards, Angel Tsankov
