Re: Need help for bash function return value
On Thu, Oct 11, 2012 at 08:01:40PM -0700, Tinni wrote:
> I am very new to the shell scripting.. Need some pointers for getting the
> return value in shell scripting.
"Return value" is an integer from 0 to 255. That's not what you want.
> I want the values ( db_host_user, db_host, ORACLE_SID) should be returned
> from the clonesel to test1.sh
>
> If i set the script inside the test1.sh as
>
> val=`ssh remoteserver '/bin/sh clonesel' `,
So, you're trying to retrieve 3 separate (string?) values from a remote
system.
> In the remote server , the script clonesel is as follows:
>
>
> #!/bin/bash
>
> echo
> echo -e "\e[1;31m\tSetup Oracle Environments \e[0m"
> echo -e "\t--"
All of that extraneous output and terminal formatting is going to get
in the way. Your best bet would be to write a separate script and
run that instead of running this clonesel thing.
> echo
> echo
> echo -en "\e[1;32m\tType DB OS User Name :\e[0m"
> read db_host_user
Wait... clonesel is interactive? You were planning to run an interactive
script on a remote system to prompt the user for information and then
send that information back to the calling script on the local system?
That doesn't make much sense. Why not simply prompt the user for the
information on the local system and skip the ssh call altogether?
(Another problem you had is that the clonesel script contains bash-specific
code, and even begins with a #!/bin/bash shebang, but you explicitly
invoked it using /bin/sh.)
---
Let's suppose you were starting from scratch and didn't have all of this
crazy code in place, and you wanted to retrieve three string values from
a remote system. This is perhaps a completely different problem from the
one you asked, but it might be helpful if you can rephrase your original
problem a bit.
Now, a script can read streams of data, and you can embed three strings
into a single stream of data. The trick is to be able to separate them
into the component strings on the receiving end. The most common way
to do that is to use some sort of delimiter between the strings. The
delimiter must be a character, or a sequence of characters, which is
guaranteed not to appear within the strings.
Let's assume that we can use a newline character as the delimiter.
Then, you could do it this way:
#!/bin/bash
{
IFS= read -r string1
IFS= read -r string2
IFS= read -r string3
} < <( ssh "$user"@"$host" bash <<'EOF'
source ~oracle/.whatever || exit
echo "$thing1"; echo "$thing2"; echo "$thing3"
EOF
)
Obviously you would substitute the appropriate variable names, and the
appropriate filenames or whatever steps you need to take to get the
remote shell into a state where it can produce the information you need.
I realize that's probably a huge number of new features all at once, so
let me break this down into pieces and explain it, and why it's done this
way.
The first part, you already know about:
#!/bin/bash
This ensures that our script will be run under bash, and not under sh.
This is necessary because we are using bash syntax that will not work
under sh. This also means that the script must be invoked as ./script
or as "bash script", NOT as "sh script" or "/bin/sh script".
The second part is a command grouping:
{
command one
command two
...
}
This grouping means that any redirections applied to the group are
inherited by all of the commands in the group. It also *does not*
use a subshell. If we had used parentheses instead of curly braces
then bash would have created a subshell for the commands, and the
read commands would have been performed inside that subshell. That
is not what we want, because when the subshell exits, all the variables
set by all the read commands will be gone.
Next we have several read commands:
IFS= read -r string1
IFS= read -r string2
IFS= read -r string3
Each of these reads one line of data from stdin (terminated by a newline
character), and puts the contents of that line into the variable named
after the -r. The "IFS=" part ensures that there will be no stripping
of leading/trailing spaces. The "-r" part ensures that there will be no
special handling of backslash characters in the data. We just want the
actual payload, with NO interpretation by the shell, and both IFS= and -r
are required to ensure that.
Because the reads are grouped together, they all share a single input.
The first one will read a line from that input, and then the second one
will read the NEXT LINE from that input, and so on.
Next we have a redirection which is applied to a group:
{
...
} < foo
The "<" character by itself means that stdin (standard input) is being
redirected from foo. The placement after the closing "}" of the group
means that the redirection applies to the entire group.
Next we have a process substitution:
<( some command )
This is a special bash feature (and the reason we needed #!/bin/bash).
It creates a virtual filename that can be used
Re: Need help for bash function return value
On Thu, 11 Oct 2012 20:01:40 -0700 (PDT), Tinni wrote: > > I am very new to the shell scripting.. Need some pointers for getting > the return value in shell scripting. comp.unix.shell
bug-bash@gnu.org
Why doesn't it exit the shell? $ set -e $ echo $(false) Shouldn't the error code of $(false) command substitution be checked by set -e before passing stdout to the echo builtin? Isn't it the most logical behavior that most people would expect of set -e? Bash version: GNU bash, version 4.2.24(1)-release (x86_64-redhat-linux-gnu) (if it matters) Thanks
bug-bash@gnu.org
On Fri, Oct 12, 2012 at 06:55:28AM -0400, Sergey Fadeev wrote: > Why doesn't it exit the shell? > $ set -e > $ echo $(false) Because the exit status of echo is 0.
bug-bash@gnu.org
On 10/12/12 06:55, quoth Sergey Fadeev: Why doesn't it exit the shell? $ set -e $ echo $(false) Shouldn't the error code of $(false) command substitution be checked by set -e before passing stdout to the echo builtin? Isn't it the most logical behavior that most people would expect of set -e? Bash version: GNU bash, version 4.2.24(1)-release (x86_64-redhat-linux-gnu) (if it matters) Thanks Seriously, can we just put a trap on all messages to this list that have the string 'set -e' in it? Just point the sender to a message that tells them to not use it. We could even tell them that the functionality is a huge misteak that was perpetrated upon the whole of mankind and that we're all just really really sorry that it ever happened. In fact the author of this message is probably dead from having generated an error by explaining it while his dash e was set. So, in conclusion, I would like to say on behalf of the FS community and mankind in general that you should not use -e any more. If it would help, I'd be willing to spend about $10 for maximum postage to send this announcement to The Proper Address so that everyone would know about this For Ever More. I'm sorry. I'm sorry that I'm sorry. And, I'm sorry that I'm sorrowful about feeling sorry. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net
Re: different exit codes in $? and ${PIPESTATUS[@]}
On 10/10/12 10:38 AM, Wladimir Sidorenko wrote:
> Dear all,
>
> After running the following command:
>
> $ ! test 0 -eq 0
>
> I can see different exit codes in $? and ${PIPESTATUS[@]}. Here, what I get
>
> $ ! test 1 -eq 0 ; echo $? ${PIPESTATUS[@]}
> 0 1
>
> $ ! test 0 -eq 0 ; echo $? ${PIPESTATUS[@]}
> 1 0
>
> I'd like to know whether that's a desired behavior or a bug.
The current behavior is the intended behavior. PIPESTATUS reflects the
"true" return status(es) of the process(es) in the pipeline, before any
inversion of the pipeline's exit status. That's what seems the most
useful.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: different exit codes in $? and ${PIPESTATUS[@]}
Ok, thanks. I'll notice this for the future. It's of course arguable,
whether PIPESTATUS stores a true value, since the '!' inversion
keyword gets ignored in this case. But if it was intended, than it's
ok.
2012/10/13 Chet Ramey :
> On 10/10/12 10:38 AM, Wladimir Sidorenko wrote:
>> Dear all,
>>
>> After running the following command:
>>
>> $ ! test 0 -eq 0
>>
>> I can see different exit codes in $? and ${PIPESTATUS[@]}. Here, what I get
>>
>> $ ! test 1 -eq 0 ; echo $? ${PIPESTATUS[@]}
>> 0 1
>>
>> $ ! test 0 -eq 0 ; echo $? ${PIPESTATUS[@]}
>> 1 0
>>
>> I'd like to know whether that's a desired behavior or a bug.
>
> The current behavior is the intended behavior. PIPESTATUS reflects the
> "true" return status(es) of the process(es) in the pipeline, before any
> inversion of the pipeline's exit status. That's what seems the most
> useful.
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: different exit codes in $? and ${PIPESTATUS[@]}
On 10/12/2012 03:36 PM, Wladimir Sidorenko wrote:
> Ok, thanks. I'll notice this for the future. It's of course arguable,
> whether PIPESTATUS stores a true value, since the '!' inversion
> keyword gets ignored in this case. But if it was intended, than it's
> ok.
Consider:
$ f() { return 2; }
$ ! f
$ echo $? ${PIPESTATUS[@]}
0 2
If PIPESTATUS included the effect of !, you would only ever be able to
see 0 or 1; but by having it be the uninverted status, you can see the
full 0-255 of the actual command prior to the inversion.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
