Ticket #71 (closed defect: invalid)

Opened 2 years ago

Last modified 2 years ago

runscript misquotes variables from /etc/conf.d

Reported by: Hugo Mildenberger <Hugo.Mildenberger@t-online.de> Owned by: roy
Priority: major Milestone:
Component: init.d scripts Version:
Keywords: Cc:

Description

Created an attachment (id=25)
example file to reproduce

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

This was posted also as Gentoo bug  http://bugs.gentoo.org/show_bug.cgi?id=219828

Attachments

openrc-quote-bug.tar.gz Download (0 bytes) - added by Hugo Mildenberger <Hugo.Mildenberger@t-online.de> 2 years ago.
example file to reproduce

Change History

Changed 2 years ago by Hugo Mildenberger <Hugo.Mildenberger@t-online.de>

example file to reproduce

comment:310 Changed 2 years ago by roy

  • Status changed from new to resolved
  • Resolution set to invalid

We'll discuss this on the Gentoo bug you openend.
However, it isn't a bug as such :)

Note: See TracTickets for help on using tickets.