All, It was pointed out to me that someone is using bash arrays in their /etc/conf.d/net file with openrc. After investigation, I have discovered that even though our documentation (net.example) and the migration guide say that we do not support bash arrays, we do in parts of oldnet. I would like to remove that support since if users have followed the migration guide they are no longer using it.
Another reason to remove this is that openrc should only have posix compatible features, and bash arrays do not fit that design.
If it's not documented, surely that's a problem with the documentation? ;-) Note that this issue caused a bit of drama a few years back, notably http://marc.info/?l=gentoo-dev&w=2&r=1&s=baselayout+bash+arrays&q=b and http://marc.info/?t=117085436800005&r=1&w=2 (there was even talk of forking baselayout so the array and POSIX people could both be happy, until I came up with (almost) the current solution), so I'd suggest proceeding with caution if you really want to do this.
Created attachment 279911 [details] 0001-add-error-messages-for-the-use-of-bash-arrays.patch All, here is the first patch I would like to add to deal with bash arrays. This patch generates error message when a bash array is detected to encourage users not to use them. What are your thoughts? William
s/eerror/ewarn/ and quote the string: ewarn "...."
Mike, the changes you suggested have been made and this has been pushed as commit e3b02ab. Should we retitle this bug and close it now and open another bug later to officially remove the bash array support?
that's fine. we'll need ebuild updates before we can remove support anyways.
Sorry to revive and old bug, but it's not "closed". Is this still open for discussion? Other than posixness, is there a technical reason why openrc shouldn't allow bash arrays? I was working on updating an init script and its conf to use associative arrays, and found that it just wouldn't work through openrc. It also didn't trigger an error (as this bug report suggests it should have). To run multiple instances of an init (sort of like net does), associative arrays make for a much more elegant and intuitive configuration. I have worked around it by using eval, but that solution just makes me feel icky... even though the end result does work. The below examples obviously need more stuff to make them work, but the POSIX route requires more variable manipulation to achieve the same result as what modern bash supports. For example: init.d/dummy init.d/dummy -> dummy.blah1 init.d/dummy -> dummy.blah2 Associative: echo ${DUMMY_PORT[${RC_SVCNAME#*.}]} POSIX: DUMMY_INSTANCE="${RC_SVCNAME#*.}" echo $(eval \${DUMMY_PORT_${DUMMY_INSTANCE^^}}) conf.d/dummy: Associative: DECLARE -A DUMMY_PORT DUMMY_PORT=12345 # this gets assigned as DUMMY_PORT[0] DUMMY_PORT[blah1]=12346 DUMMY_PORT[blah2]=12347 POSIX: DUMMY_PORT=12345 DUMMY_PORT_BLAH1=12346 DUMMY_PORT_BLAH2=12347 The associative route would allow some fun stuff like this in the conf file too: DECLARE -A DUMMY_PORT=("[blah1]" "[blah2]") DUMMY_BASE_PORT=12345 __PORT=${DUMMY_BASE_PORT} for i in ${!DUMMY_PORT[@]} ; do DUMMY_PORT[$i]=$(( __PORT++ )) ; done DUMMY_PORT=${DUMMY_BASE_PORT} # because I don't care what the port # is, each daemon just needs its own port
(In reply to Scott Jones from comment #7) > Sorry to revive and old bug, but it's not "closed". Is this still open for > discussion? OpenRC needs to be able to run without bash present on the system, and init scripts cannot assume that their environment is full bash. > Other than posixness, is there a technical reason why openrc shouldn't allow > bash arrays? I was working on updating an init script and its conf to use > associative arrays, and found that it just wouldn't work through openrc. It > also didn't trigger an error (as this bug report suggests it should have). That should have triggered an error, can you please report it as a new bug? > > To run multiple instances of an init (sort of like net does), associative > arrays make for a much more elegant and intuitive configuration. I have > worked around it by using eval, but that solution just makes me feel icky... > even though the end result does work. Look at mysql-init-scripts, they support multiple instances fine without arrays (admittedly, they did use arrays before, but moved away from them).
Thanks! I'll check out mysql-init-scripts and create a bug report for how to reproduce what I was doing that didn't generate an error. I'll also make sure my new deluge init script is posix compliant before posting it :)
