1

I am a bit at a loss right now as to why a script of mine does not work as I perceived it.

Since id3v2 is a bit complex to use, I tried to simplify its uses by writing a script around it. The parts which are mine work perfectly fine, but coming to handing the collected information over to id3v2, it fails when any of the switch values have spaces in there, even though I forced quotations inside the variables.

The usage for id3v2 requires each switch to be followed by a value. Everything else is considered a file.

So, in order to define the title the switch would look like this:

--TIT2 "Beautiful Stranger"

The switch without and the value with quotation marks to cope with whitespace.

To be able to fully omit any switch without building a new command line inside the script, I thought it would be smart to submit the variables without quotations with forced quotations inside the value, which I hoped where unwrapped. Consider the following:

...
sTitle="--TIT2 \"Beautiful Stranger\""
...
/usr/bin/id3v2 ${sTitle} ${sArtist} ${sAlbum} ${sTrack} ${sYear} ${sGenre} ${sGrouping} "${aFiles[${iFile}]}"

However, while the result looks good using the above line with echo, using id3v2 provides me the message Couldn't stat file 'Stranger"' (basically, the second part of my title plus finalizing quotation cannot be found, which is obviously correct).

Disappointed that id3v2 apparently does not adhere to the unwrapped forced quotations, I modified my script to split the variables from the switches and quoted them on the target command line instead:

...
sTitleHead="--TIT2"
sTitle="Beautiful Stranger"
...
/usr/bin/id3v2 "${sTitleHead}" "${sTitle}" "${sArtistHead}" "${sArtist}" "${sAlbumHead}" "${sAlbum}" "${sTrackHead}" "${sTrack}" "${sYearHead}" "${sYear}" "${sGenreHead}" "${sGenre}" "${sGroupingHead}" "${sGrouping}" "${aFiles[${iFile}]}"

This works as long as all variables are used, but fails if one (or more) variables are omitted. The error message there is Couldn't stat file ''. It seems that it still finds the quotes on the command line and tries them as a file name, even though when I omit a variable, I typically unset or set them as zero-length string (tried both).

I also tried to remove quotations from my ...Head variables, just in case they are not properly detected as parameters, but the result is the same.

Does anyone know how to convince id3v2 on how to take the command line parameters without giving out?

Alternatively, if there is a easier scriptable program around, I am also thankful.

Phoenix
  • 286
  • 1
    You should store options like this in an array instead of a variable. – jesse_b Aug 03 '19 at 20:05
  • Hmm... I will give it a try. Have not thought of that indeed. – Phoenix Aug 03 '19 at 20:07
  • 1
    Another possibility is to use conditional expansion, like /usr/bin/id3v2 ${sTitle:+ --TIT2 "${sTitle}"}, which leaves out both the flag and (double-quoted) arg if sTitle is undefined. See my answer to this SuperUser question. – Gordon Davisson Aug 03 '19 at 20:21
  • @Jesse_b That seems to have worked indeed now. As it did not work initially, I am still wondering what the difference between ${aOptions[*]} and ${aOptions[@]} is. I was under the impression that they were interchangeable. – Phoenix Aug 03 '19 at 20:34
  • @GordonDavisson a neat alternative solution. Though I agree that the array version of Jesse_b definitely sounds like something I will use in the future more often. – Phoenix Aug 03 '19 at 20:37
  • @Phoenix You want "${aOptions[@]}" to expand the array; both the double-quotes and @ are required for it to work right. – Gordon Davisson Aug 03 '19 at 20:55
  • @GordonDavisson that is what I found out as well. ;-) The question (inside the comments) remains, however. – Phoenix Aug 03 '19 at 20:56
  • Without double-quotes, ${aOptions[*]} and ${aOptions[@]} are equivalent. With double-quotes they're quite a bit different: * merges all array elements into a single string, but @ treats each element as a separate string. See this SO answer for details. – Gordon Davisson Aug 03 '19 at 20:59
  • @GordonDavisson Perfect! Thanks! That is clear then. – Phoenix Aug 03 '19 at 21:01
  • @Jesse_b Thanks to you, of course, as well for pointing me to the answer. The suggestions did not hold it, so I posted mine. Thanks again! – Phoenix Aug 03 '19 at 21:02

0 Answers0