Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 219828 - runscript misquotes variables from /etc/conf.d
Summary: runscript misquotes variables from /etc/conf.d
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-30 11:55 UTC by Hugo Mildenberger
Modified: 2008-05-01 15:17 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
example file to reproduce (openrc-quote-bug.tar.gz,988 bytes, application/octet-stream)
2008-04-30 12:22 UTC, Hugo Mildenberger
Details
eval arg demonstration (eval.sh,258 bytes, text/plain)
2008-05-01 12:04 UTC, Roy Marples
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hugo Mildenberger 2008-04-30 11:55:33 UTC
I recently wrote a init script for storescp ( which is part of dcmtk DICOM utility tool set). This strange program uses a command-line switch --exec-on-eostudy "some_script #p #f #a #c". Therein, the shell comment character is used as a placeholder (don't know who had invented this) 

However, it is simply impossible to put this into a configuration variable within /etc/conf.d/dicom-storescp:

DICOM_WRITE_DIR="--exec-on-eostudy '/usr/bin/dcm_write_dir #p #f #a #c'"

DICOM_STORESCP_OPTS="--disable-tls --access-full --output-directory /home/dicom  --sort-conc-studies rec_ --rename-on-eostudy --eostudy-timeout 2  --promiscuous  ${DICOM_WRITE_DIR} "


While expecting to get this translated into --exec-on-eostudy '/usr/bin/dcm_write_dir #p #f #a #c', I got (whatever I 
tried) something like:

start-stop-daemon --start --quiet --background --user dicom:dicom --exec /usr/bin/storescp -- --disable-tls --access-full --output-directory /home/dicom --sort-conc-studies rec_ --rename-on-eostudy --eostudy-timeout 2 --promiscuous --exec-on-eostudy ''\''/usr/bin/dcm_write_dir' '#p' '#f' '#a' '#c'\''' 1040

The problem with storescp is, that it expects the argument of --exec-on-eostudy to be a string as a single argument, however containing shell comment characters. Whereas the problem with runscript is, that there is currently no way to pass a string argument to the init script "as is", it is either under-, over- or misquoted, whatever you try as a workaround.

- if I leave out the single-quotation marks: underquoted, argc mismatch
- if I use ": overquoted
- if I use ': overquoted

The solution would be not to make any substitution if an unescaped single quotation mark is encountered, until the next occurence of an unescaped single quotation mark. This is how i.e. bash handles it.

Reproducible: Always

Steps to Reproduce:
1. use the attached tar archive 
2.
3.
Actual Results:  
start-stop-daemon --start --quiet --background --user dicom:dicom --exec /usr/bin/storescp -- --disable-tls --access-full --output-directory /home/dicom --sort-conc-studies rec_ --rename-on-eostudy --eostudy-timeout 2 --promiscuous --exec-on-eostudy ''\''/usr/bin/dcm_write_dir' '#p' '#f' '#a' '#c'\''' 1040

Expected Results:  
start-stop-daemon --start --quiet --background --user dicom:dicom --exec /usr/bin/storescp -- --disable-tls --access-full --output-directory /home/dicom --sort-conc-studies rec_ --rename-on-eostudy --eostudy-timeout 2 --promiscuous --exec-on-eostudy '/usr/bin/dcm_write_dir #p #f #a #c' 1040

Will attach the archive containing an example later containing the full example later (because this form does not provide the possibility to attach a file.)

As far as I see, the problem is not related to bash, because a bash script I wrote to test the very same construct handled it as expected. A workaround is to put the argument directly into the init-script (however, this breaks with the concept )

The problem was already there with openrc-0.2.2 and persists in 0.2.3

 sys-apps/openrc
      Latest version available: 0.2.3
      Latest version installed: 0.2.3
      Size of files: 139 kB
      Homepage:      http://roy.marples.name/openrc
      Description:   OpenRC manages the services, startup and shutdown of a host
      License:       BSD-2
Comment 1 Hugo Mildenberger 2008-04-30 12:22:03 UTC
Created attachment 151410 [details]
example file to reproduce
Comment 2 Roy Marples 2008-05-01 11:14:24 UTC
Any reason why you can't use prefix the start-stop-daemon command with eval?
Comment 3 Hugo Mildenberger 2008-05-01 11:49:47 UTC
(In reply to comment #2)
> Any reason why you can't use prefix the start-stop-daemon command with eval?
>
No, Roy, arguable there is no ethically justifiable reason not to use eval. Thank you very much for your accurate response. Prefixing with eval solved the problem quickly. However, could you explain why eval is needed with runscript, but not with pure bash? 
Comment 4 Roy Marples 2008-05-01 12:04:55 UTC
Created attachment 151504 [details]
eval arg demonstration

Try running this script to see why you need to use eval.
It's not runscript specific at all :)
Comment 5 Hugo Mildenberger 2008-05-01 14:43:49 UTC
(In reply to comment #4)
> Try running this script to see why you need to use eval.
> It's not runscript specific at all :)

True. Lesson learned: besides eval, nobody respects quotes.
 
Comment 6 Roy Marples 2008-05-01 14:59:20 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Try running this script to see why you need to use eval.
> > It's not runscript specific at all :)
> 
> True. Lesson learned: besides eval, nobody respects quotes.

You mean quotes in variables :)
You may wish to close this bug now ;)

Comment 7 Hugo Mildenberger 2008-05-01 15:17:50 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Try running this script to see why you need to use eval.
> > > It's not runscript specific at all :)
> > 
> > True. Lesson learned: besides eval, nobody respects quotes.
> 
> You mean quotes in variables :)
So you mean I only meant variables? I wish real live had an eval program too.

> You may wish to close this bug now ;)
For sure. After having read your post at http://roy.marples.name/node/389 I will close it even more quickly. Thank you very much for the hints and for the insight you taught me, too.