GNOME Bugzilla – Bug 143473
[cli-tools] newline in property value in gst-launch string breaks parsing
Last modified: 2005-10-24 10:28:11 UTC
Run: $ gst-launch filesrc location="`echo "blah\nblah"`" Error message: WARNING: erroneous pipeline: no element "blah" Trying to run anyway. RUNNING pipeline ... ERROR: from element /pipeline0/filesrc0: Resource not found. ERROR: pipeline doesn't want to play. It also appears that the newline isn't put in the property value, but I don't know an easy way to prove that.
What you want is: echo -n "blah\nblah" See echo(1) for more details.
That gives the same error message. gst-launch is still not parsing the property value correctly.
What are you _really_ trying to do? I'd need significant motivation to fix a bug concerning filenames containing strange characters. How am I supposed to interpret this bug when `echo "blah\nblah"` gives blah\nblah which is exactly as I expect?
Perhaps you mean for echo to process escape codes with -e option?
I'm really trying to write the element in bug #141686. I want to include a newline in the format string, which is specified as a property. But gst-launch doesn't seem to be able to parse property values containing newlines, hence this bug. I figured it'd be easier to give you a test case involving filesrc since you actually have that element installed. I see the -e problem: zsh (what I'm running) doesn't need -e to process escapes, os x never processes them, and bash and gnu need -e. printf doesn't have these problems, so my problematic gst-launch command should be: gst-launch filesrc location="`printf "blah\nblah"`" I'd like you to interpret this bug as "please show me a way to, from a shell prompt, include a newline character in a element's property value. If, as I suspect, there's no way to do it, please fix that." I think the symptom of this bug is these two lines in the error message: WARNING: erroneous pipeline: no element "blah" Trying to run anyway. because I'm never asking for a "blah" element. Do none of you get this part of the error message? I am running on os x, so it's possible that's causing the problem, but it would be a very strange os dependency.
Sorry nobody got back quicker. It's likely that gst-launch doesn't handle newlines correctly. I'm not particularly surprised, since it's supposed to be a test tool, not a general-purpose interface to gstreamer internals. So problems like this are handled as time permits. Please feel free to dive into gst_parse_launch(), in gstreamer/gst/parse/parse.y. Personally, I think gst-launch lines should handle escape sequences themselves, so you could use gst-launch 'filesrc location="blah\nblah" ! fakesink' and have the \n correctly substituted.
Confirming this is still the behaviour of HEAD CVS.
Created attachment 53810 [details] [review] Proposed patch to allow special spacing characters as non string delimiters I m not commiting this to CVS because i would like to debate/check that this is not going to have nasty border effects. Indeed accepting vert/horiz tabs, carriage return, form feed and new line as characters of a string can be a bit risky. Can't really see a case where that would break for gst-launch though. Feedback welcome.
So finally i ve discussed about it with Wim and we really need to have spacing character like newline, form feed etc.. being lexical separators. If you need to assign a string to an element property you have to use quotes. The reason why it did not work for you is that gst-launch and bash are basically removing the quotes around blah\nblah and then flex consider \n as a string terminator. Flex will handle "blah\nblah" or 'blah\nblah' correctly though. I m closing this bug.