Bug 3025 - hush: 'eval' built-in fails on multiline strings
Summary: hush: 'eval' built-in fails on multiline strings
Status: RESOLVED INVALID
Alias: None
Product: Busybox
Classification: Unclassified
Component: Standard Compliance (show other bugs)
Version: 1.13.x
Hardware: Other Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-30 17:37 UTC by Kévin PETIT
Modified: 2010-12-30 22:56 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kévin PETIT 2010-12-30 17:37:01 UTC
Platform : Lantronix Xport Pro (m68knommu, Coldfire)
Distrib  : uClinux

I'm using a program that outputs lines like this: 

----------------------
VAR1="val1"
VAR2="val2"
etc
----------------------

Willing to use these as variables in a script without using a temporary file, I do (simple example): 
---------------------------
eval "`./myprog`"

echo $VAR1
echo $VAR2
---------------------------

This works with bash but not with hush (which is the only shell provided with busybox that works on my platform): only first var is ok. I tried playing a little with the IFS variable, without any satisfying result. I had to modify my program to output all variable assignations on a single line.

Is this behavior expected ?
Comment 1 Denys Vlasenko 2010-12-30 22:28:30 UTC
Current git doesn't have this bug:

$ cat z2
#!/bin/sh
{
echo '#!/bin/sh'
echo 'echo VAR1="val1"'
echo 'echo VAR2="val2"'
} >z1
chmod 755 z1
VAR1="a"
VAR2="b"
echo "before: VAR1='$VAR1'"
echo "before: VAR2='$VAR2'"
eval "`./z1`"
echo "after: VAR1='$VAR1'"
echo "after: VAR2='$VAR2'"

$ ./busybox hush z2
before: VAR1='a'
before: VAR2='b'
after: VAR1='val1'
after: VAR2='val2'

# ./busybox | head -1
BusyBox v1.19.0.git (2010-12-30 23:21:08 CET) multi-call binary.
Comment 2 Kévin PETIT 2010-12-30 22:56:06 UTC
Thanks for your help Denys. 

I now know this is considered as a bug. I'll be upgrading if I can't cope with my workaround.

I'm closing the bug.