#4359 Custom Command Menu Parameter not working as documented

0.82
open
nobody
5
2014-08-26
2014-01-24
Bee Kay
No

I had been using a "text" field to put in my path "/builds/weekly/" into my variable for a shell script, which works just fine.

I converted the same field to a "menu" parameter, with the "/builds/weekly/, WeeklyBuild" (sans parentheses of course) as the one of two entries in the file referenced by the menu parameter. Sadly, this syntax passed in the comma as well.

I then tried without the comma, (a space is apparently a delimiter as well) and found that the string appeared correct when using "echo $pathname is the Path", on screen at least.

However, this isn't true when passing the data into a shell script. There must be unprintable characters appended, as my ant script fails during an FTP task, even though it worked as a "text" field previously moments before.

I will be trying to use "menu" without the "variable_value Text_to_display_in_menu" format, and just show the raw paths instead. I am suspecting this will work properly.

It's very odd, as the logs show it as targeting the right server and path, yet "0 files found" - change it back to a text field, and it works on the first try. Something about the "menu" parameter is just not passing the data verbatim.

Related

Bugs: #4359

Discussion

  • Jamie Cameron

    Jamie Cameron - 2014-01-24

    The format of the parameters file can be like :

    /builds/weekly/ WeeklyBuild

    or :

    "/builds/weekly/" "WeeklyBuild"

    There is no need for a comma - spaces are the only delimiter.

     
  • Bee Kay

    Bee Kay - 2014-01-24

    Thanks for the quick response.  My problem is that when the value got passed in, although it appears on screen correctly when printed out, it does not behave the same as the Text field variable. I will write a much smaller sample shell and xml script and post the custom command html and the menu file for your review.

    -------- Original message --------
    From: Jamie Cameron jcameron@users.sf.net
    Date:01/23/2014 10:00 PM (GMT-08:00)
    To: "[webadmin:bugs]" 4359@bugs.webadmin.p.re.sf.net
    Subject: [webadmin:bugs] #4359 Custom Command Menu Parameter not working as documented

    The format of the parameters file can be like :

    /builds/weekly/ WeeklyBuild

    or :

    "/builds/weekly/" "WeeklyBuild"

    There is no need for a comma - spaces are the only delimiter.

    [bugs:#4359] Custom Command Menu Parameter not working as documented

    Status: open
    Labels: webmin menu parameter
    Created: Fri Jan 24, 2014 01:48 AM UTC by Bee Kay
    Last Updated: Fri Jan 24, 2014 01:48 AM UTC
    Owner: nobody

    I had been using a "text" field to put in my path "/builds/weekly/" into my variable for a shell script, which works just fine.

    I converted the same field to a "menu" parameter, with the "/builds/weekly/, WeeklyBuild" (sans parentheses of course) as the one of two entries in the file referenced by the menu parameter. Sadly, this syntax passed in the comma as well.

    I then tried without the comma, (a space is apparently a delimiter as well) and found that the string appeared correct when using "echo $pathname is the Path", on screen at least.

    However, this isn't true when passing the data into a shell script. There must be unprintable characters appended, as my ant script fails during an FTP task, even though it worked as a "text" field previously moments before.

    I will be trying to use "menu" without the "variable_value Text_to_display_in_menu" format, and just show the raw paths instead. I am suspecting this will work properly.

    It's very odd, as the logs show it as targeting the right server and path, yet "0 files found" - change it back to a text field, and it works on the first try. Something about the "menu" parameter is just not passing the data verbatim.

    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/webadmin/bugs/4359/

    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #4359


Log in to post a comment.