houaq / shflags Goto Github PK

What steps will reproduce the problem?
1. use DEFINE_boolean 'force' false ''

What is the expected output?
USAGE: ./test.sh [flags]
flags:
  -f,--[no]force:  (default: false)
  -h,--[no]help:  show this help (default: false)


What do you see instead?
USAGE: ./test.sh [flags]
flags:
flags:ERROR invalid flag name (__flags_force_help)
  -f,--[no]force:  (default: false)
  -h,--[no]help:  show this help (default: false)


What version of the product are you using? On what operating system?
shflags-1.0.3, bash 4.2.24, openSUSE 12.2 x86_64

What steps will reproduce the problem?
1. Add --nohelp as an option. By default help is already disabled, and nohelp 
shouldn't enable it. 

What steps will reproduce the problem?
# source shflags
. ./shflags-1.0.3/src/shflags

# define a 'name' command-line string flag
DEFINE_string 'name' 'world' 'name to say hello to' 'n'


function main ()
{
 # parse the command-line
 FLAGS "$@" || exit 1
 eval set -- "${FLAGS_ARGV}"

 echo "Hello, ${FLAGS_name}!"
}

main


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
shflags-1.0.3

Please provide any additional information below.
when parsing the command line is out of main function, everything is fine

$ ./hello_world.sh --help
flags:WARN getopt: illegal option -- -
getopt: illegal option -- e
getopt: illegal option -- l
getopt: illegal option -- p
 -h --
flags:FATAL unable to parse provided options with getopt.

---

$ ./hello_world.sh --name Bob
flags:WARN getopt: illegal option -- -
 -n ame -- Bob
flags:FATAL unable to parse provided options with getopt.

---

$ which getopt
/usr/bin/getopt

What steps will reproduce the problem?
1. define a flag, then call the script with -h or --help
2. output will always show flag with [no] option - which is correct but
confusing to my users...

What is the expected output? What do you see instead?
Would love to have the option to see (as an example):

USAGE: /usr/local/scripts/private_db [flags] project
flags:
  -u,--update:  update the private database with the current live database
(default: false)
  -d,--delete:  delete the private database (default: false)
  -h,--help:  show this help (default: false)

instead of 

USAGE: /usr/local/scripts/private_db [flags] project
flags:
  -u,--[no]update:  update the private database with the current live
database (default: false)
  -d,--[no]delete:  delete the private database (default: false)
  -h,--[no]help:  show this help (default: false)


What version of the product are you using? On what operating system?
133 on Ubuntu 9.04 

Please provide any additional information below.
Thanks!!!  shflags is very useful!

What steps will reproduce the problem?
1. Run shflags-1.0.3/src$ ./shflags_test_public.sh
2. Test testStandardHelpOutput fails

What is the expected output? What do you see instead?
Expect all tests to pass
I changed line 91 in the file above so that the diff output is sent to stdout 
instead of /dev/null
From that it appears that the line wrapping expected by the test is not 
occurring:
6,9c6,7
<   -D  testing of a long description to force wrap of default value
<       (default: 'blah')
<   -F  testing of long default value
<       (default: 'this_is_a_long_default_value_to_force_alternate_indentation')

---
>   -D  testing of a long description to force wrap of default value (default: 
'blah')
>   -F  testing of long default value (default: 
'this_is_a_long_default_value_to_force_alternate_indentation')
ASSERT:unexpected help output

What version of the product are you using? On what operating system?
shflags 1.0.3 on Mac OS X Lion 10.7.2 (11C74)

Please provide any additional information below.
Thanks for creating and sharing this and your other shell libraries, great work!

DEFINE_string str '' 'some string'
FLAGS "$@" || exit; shift ${FLAGS_ARGC}
echo "-- $1 --"

# without '=' the result is correct
$ ./script --str abc 123
-- 123 --

# with '-' the result is incorrect
./script --str=abc 123
--  --

Platform is Ubuntu Dapper 6.06.

What steps will reproduce the problem?
1. Use the following sample file (call it bug.sh):

#!/bin/bash - 

. ./shflags

DEFINE_boolean foo false \
    "To foo or not to foo"

# Parse command line options.
FLAGS "$@" || exit $?
eval set -- "${FLAGS_ARGV}"

echo ${FLAGS_foo}

2. Run and observe the output of the following commands:

$ ./bug.sh --foo
0
$ ./bug.sh --nofoo
1
$ ./bug.sh --foo=0
flags:WARN getopt: option `--foo' doesn't allow an argument
 --
flags:FATAL unable to parse provided options with getopt.
$ ./bug.sh --foo=1
flags:WARN getopt: option `--foo' doesn't allow an argument
 --
flags:FATAL unable to parse provided options with getopt.

What is the expected output? What do you see instead?
See above

What version of the product are you using? On what operating system?
gflags 1.0.3 on Mac. I'm using the getopt from homebrew, so it does support 
long arguments.

Please provide any additional information below.
The comments in shflags might be out of date. Specifically, the section about 
boolean flags includes this:

#   Alternately, you can say
#     --myflag=true  or --myflag=t or --myflag=0  or
#     --myflag=false or --myflag=f or --myflag=1

There are times where a user might want to define a flag for internal use,
but not provide it in the help output.

What steps will reproduce the problem?
1. login to a freebsd system.
2. checkout the 1.0.3 version
3. run in the example dir: ./hello_world.sh -n toto


What is the expected output? What do you see instead?
expected:
./hello_world.sh -n toto
Hello, toto!

seen:
expr: illegal option -- n
usage: expr [-e] expression
flags:FATAL unrecognized option ()

What version of the product are you using? On what operating system?
1.0.3 on freebsd.

Please provide any additional information below.
See the attached file for a working patch.  Apply with patch -p1 < shaflags.path

The command expr is different for all different systems, Linux, *Nix, BSDm, 
WinGW etc.

The majority of the expr commands can be replaced with pure shell commands.

The patch replaces all expr except for the one used for the FLAGS_ARGC variable 
which obsolete per 1.0.3.

The development of this improvement can be followed on github, 
https://github.com/petervanderdoes/shFlags/tree/feature/replace-expr-command

Statements execute 'expr' such as:
_flags_opt_=`expr "${_flags_opt_}" : '-\(.*\)'`
should add '--' to prevent error from the variable begins with a hyphen.
i.e., _flags_opt_=`expr -- "${_flags_opt_}" : '-\(.*\)'`

OS: FreeBSD 8.0 Release

Branch name: HEAD (r190)

Purpose of code changes on this branch:
Addressing issues in Issue 21.

When reviewing my code changes, please focus on:
The usage of expr.

for debugging output it would be helpful to have the method iterating all the 
flags and showing the value set for the current call provided with shflags.

It could make error analysis easier and would take the burden from the script 
developer to do so manually if needed.

What steps will reproduce the problem?
1. Define a long option name with a '-' character like this :
DEFINE_string 'overwrite-revision' '' 'overwrite the revision number' in the 
script,
2. call the script with '-h' flag.
3. the script exit abnormally and print some error messages.

What is the expected output? What do you see instead?
./shflags: line 315: FLAGS_overwrite-revision=: command not found
./shflags: line 316: __flags_overwrite-revision_type=4: command not found
./shflags: line 318: __flags_overwrite-revision_default=: command not found
./shflags: line 319: __flags_overwrite-revision_help=overwrite the revision 
number: command not found
./shflags: line 320: __flags_overwrite-revision_short=~: command not found
./shflags: line 362: [: revision_type:-: integer expression expected
./shflags: line 370: [: revision_type:-: integer expression expected
USAGE: ./build [flags] args
flags:
./shflags: line 930: [: revision_type:-: integer expression expected
./shflags: line 947: flags_defaultStr_: unbound variable


What version of the product are you using? On what operating system?
shflags 1.0.3 on Linux

Please provide any additional information below.

Purpose of code changesL
Several tests were wrong. The wrong item was checked.
Added three additional tests.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

There isn't currently any way to mark a flag as required for operation of the 
program. It would be nice to have a uniform way for a flag to be marked as 
required.


What version of the product are you using? On what operating system?
shflags-1.0.3.tgz, Centos 5.4 and archlinux

I love this tool and am using it enthusiastically. however, i am having a 
problem in that I have a lot of flags with long names and they don't abbreviate 
well. Are short flags required? Are there any workarounds that would extend the 
number of short flags available?

Just some minor typo fixes, in comments and output.

it would be nice to include to wiki the way to print the help for example for 
the no flags/arguments present.

The way it worked for me on the sample program documented here: 
http://stackoverflow.com/questions/17521380/bash-showing-usage-help-on-no-argume
nts-with-shflags/17521842#17521842

was:
...
# parse the command-line
FLAGS "$@" || exit $?
if [ $# == 0 ] ; then
    flags_help
    exit 1;
fi
eval set -- "${FLAGS_ARGV}"
...

In recent builds, the help output automatically adds the default values. The 
determination whether 
to include that default on the same line as the help description or on a new 
line is using the 
constant of 80. A dynamic check would be better.

* Using stty:
set -- `stty size`
LINES=$1
COLUMNS=$2

* Using tput:
LINES=`tput lines`
COLUMNS=`tput cols`

Sometimes it's useful to have a boolean flag that doesn't have a negate option.
For example:
DEFINE_boolean 'force' false 'force overwriting' 'f'

It's not needed to have a --noforce for this option as omitting the flag has 
the same result.

We can add an exclamation mark at the end of the flag name to indicate there is 
no negate option for this flag.
In the above eample the new define statement would be:
DEFINE_boolean 'force!' false 'force overwriting' 'f'

The patch already has this for the build in help flag.
DEFINE_boolean 'help!' false 'show this help' 'h'

If testing is happening on a shell, resourcing shflags will set all FLAGS_* 
variables readonly. A check 
should be added to not try to reset variables readonly.

Purpose of code changes:
Remove the use of an external command to determine if an item is in a list.

When reviewing my code changes, please focus on:
The function _flags_itemInList

version: 1.0.2

The following code produces an error when help is called for.

DEFINE_integer 'quarter' '' 'quarter to display [1-4]' 'q'

flags:ERROR invalid flag name (__flags_quarter_default)

Hi!

While attempting to include shflags into a Fedora package, I noticed that the 
LGPL-2.1 license included in the source code repository contains an old FSF 
address. It would be great if you could at some point update your copy of the 
LGPL 2.1 license to contain the correct address of the FSF. An up to date copy 
of the license can be found here: 
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

Thanks!
Tobi

Running any script while passing an invalid flag will incorrectly generate an 
"only short flags" 
warning on Linux.

flags:WARN getopt on this platform supports only short flags
flags:FATAL unable to parse the provided options with getopt.

It would be very useful to have an option to provide newline in string of the 
FLAGS_HELP (custom usage description) variable.

So that something to following:
FLAGS_HELP="Some usage text\nnew line of the text\nUSAGE: $0 [flags]"

would output:
Some usage text
new line of the text
USAGE: $0 [flags]

the script does not source the library but closes down directly due to an 
error somehow...

well, one problem seems to be related to the "grep" command around this 
lines in shflags:

    232   # TODO(kward): check for validity of the flag name (e.g. dashes)
    233
    234   # check whether the flag name is reserved
    235   echo " ${FLAGS_RESERVED} " |grep " ${_flags_name_} " >/dev/null
    236 if [ $? -eq 0 ]; then
    237 flags_error="flag name (${_flags_name_}) is reserved"
    238 _flags_return_=${FLAGS_ERROR}
    239 fi
    240
If the calling script uses -e, the code finishes in the line 235 because the 
grep returns "1" within the value "$?"
If a -v switch is used, the output is inverted and with the line
if [ $? -eq 1 ]; then

In r146 the error message for the function _flags_getFlagInfo changed from
flags_error="invalid flag name (${_flags_nameVar_})"

to

flags_error="missing flag info variable (${_flags_infoVar_})"

Which causes the test shflags_test_private.sh -> testGetFlagInfo() to fail.

Attached file fixes the test.