Passing variable as input & storing output in other variable

I have a below syntax its working fine...

var12=$(ps -ef | grep apache | awk '{print $2,$4}')

Im getting expected output as below:

printf "%b\n" "${VAR12}"
dell 123
dell 456
dell 457

Now I wrote a while loop.. the output of VAR12 should be passed as input parameters to while loop and results to be stored in a variable called as logdata

while read userpid username
do 
logdata=$(ssh -n $username@dell.sys.com pwdx $userpid | awk '{print $2}')
done < $var12

now my aganda is to store the output in a variables instead of storing output in a file. I have created a code but I m getting unexpected results & since last 2hrs I got stuck up with this

You do realize that the redirection in:

while ...
do 
...
done < $var12

only works if $var12 does not contain any IFS characters and only works if $var12 expands to the name of a file, right???

If var12 contains 3 lines of data and you want to read data from those lines using a while loop, that would be something more like:

printf '%s\n' "$var12" | while read userpid username
do 
	logdata=$(ssh -n $username@dell.sys.com pwdx $userpid | awk '{print $2}')
done

but this doesn't make any sense either. Why set up a loop invoking ssh to set a variable that is not used in the loop. So only the value of logdata set by the last execution of the loop will make any difference after the loop terminates. And, since the loop is now in a pipeline which may be run in a subshell environment, even the last value may disappear when the loop ends (depending on what shell you're using).

And, of course, you haven't said anything about what operating system you're using, what shell you're using, nor what diagnostics were printed when you tried running your script... So, we're left making lots of guesses based on minimal input.

Why is it so important to avoid using a file if you are using a script that needs to read input from a file???

Hello Don,
THanks for your response,
I m using solaris 5.0 (bash script)
Yes, you are right..the loop is in a pipeline which is running in a subshell environment, at the end it is storing only the output of last iteration in variable logdata..........

But suppose If I store output in a file then I m getting accurate results.

ssh -n $username@dell.sys.com pwdx $userpid | awk '{print $2}' >> file

can you suggest your comments on this..

Hold on - you run a pwdx on a PID that is from another system??

Hello
NO, We run a pwdx command from remote machine to local server.
I.e By default we connect to remote machine then we use ssh hostname connect to respective servers..

Not really...

You're using an operating system that is about 25 years old. And, on any Solaris 5.x system, you shouldn't be using /usr/bin/awk or /bin/awk (I've forgotten which it was in Solaris 5.0) unless you're using it to run code that you copied from a UNIX System V or earlier AT&T UNIX system.

You have shown us two code segments. And, you've told us you're concerned about how variables are being used. But, whether you set a variable named logdata or you save the output in a file named file , you haven't shown us what output is stored there, you haven't told us what output you want to store there, and you haven't shown us any code that uses the data once it is saved (so we don't know whether a variable, a file, or a pipeline reading it directly would make more sense).

The two code segments you showed us:

var12=$(ps -ef | grep apache | awk '{print $2,$4}')

and

while read userpid username
do 
logdata=$(ssh -n $username@dell.sys.com pwdx $userpid | awk '{print $2}')
done < $var12

could easily be combined without using any variables or files (except to store the final output) and getting rid of one invocation of awk with:

ps -ef | grep apache | while read junk userpid junk username junk
do 	ssh -n $username@dell.sys.com pwdx $userpid | nawk '{print $2}'
done > file

I never used the bash that came with Solaris 5.0, but the grep could also be removed from the pipeline using bash built-ins. I could easily do it with the ksh on Solaris 5.0, but I don't know what parameter expansions were available in bash at that time.