16 Aug, 2017

2 commits

  • We are now using an env_ prefix for environment functions. Rename these
    two functions for consistency. Also add function comments in common.h.

    Quite a few places use getenv() in a condition context, provoking a
    warning from checkpatch. These are fixed up in this patch also.

    Suggested-by: Wolfgang Denk
    Signed-off-by: Simon Glass

    Simon Glass
     
  • We are now using an env_ prefix for environment functions. Rename setenv()
    for consistency. Also add function comments in common.h.

    Suggested-by: Wolfgang Denk
    Signed-off-by: Simon Glass

    Simon Glass
     

08 Feb, 2016

2 commits


13 Dec, 2015

1 commit


06 Dec, 2015

2 commits

  • Need to free memory avoid memory leak, when error.

    Signed-off-by: Peng Fan
    Reviewed-by: Simon Glass
    Cc: Simon Glass
    Cc: Tom Rini

    Peng Fan
     
  • Condition "(value == NULL && ++value == NULL)" actully will
    always return false.

    Instead, use condition "(value == NULL || *(value + 1) == 0)" to detect
    such expression "c=". To "c=", *(value + 1) is 0, so directly return -1,
    but not continue.

    Signed-off-by: Peng Fan
    Cc: Rabin Vincent
    Cc: Simon Glass
    Cc: Tom Rini
    Reviewed-by: Simon Glass

    Peng Fan
     

20 Nov, 2015

1 commit


25 Nov, 2014

1 commit

  • 128059b92 ("hush: fix segfault on syntax error") attempted to fix a
    segfault on syntax errors, but it broke Ctrl-C handling, and the
    assumption that it made, that rcode could not be -1, is incorrect.
    Revert this change.

    Reported-by: Stephen Warren
    Reported-by: Przemyslaw Marczak
    Signed-off-by: Rabin Vincent

    Rabin Vincent
     

08 Nov, 2014

3 commits

  • run_command() returns success even if the command had a syntax error;
    correct this behaviour.

    Signed-off-by: Rabin Vincent
    Acked-by: Simon Glass <sjg@chromium.org)

    Rabin Vincent
     
  • Hush segfaults if it sees a syntax error while attempting to parse a
    command:

    $ ./u-boot -c "'"
    ...
    syntax error
    Segmentation fault (core dumped)

    This is due to a NULL pointer dereference of in_str->p in static_peek().
    The problem is that the exit condition for the loop in
    parse_stream_outer() checks for rcode not being -1, but rcode is only
    ever 0 or 1.

    Signed-off-by: Rabin Vincent
    Acked-by: Simon Glass <sjg@chromium.org)

    Rabin Vincent
     
  • Attempting to run:
    - an empty string
    - a string with just spaces

    returns different error codes, 1 for the empty string and 0
    for the string with just spaces. Make both of them return
    0 for consistency.

    Signed-off-by: Rabin Vincent
    Acked-by: Simon Glass <sjg@chromium.org)

    Rabin Vincent
     

27 Oct, 2014

1 commit

  • The run command treats each argument an an environment variable. It gets the
    value of each variable and executes it as a command. If an environment
    variable contains a newline and the hush cli is used, it is supposed to
    execute each line one after the other.

    Normally a newline signals to hush to exit - this is used in normal command
    line entry - after a command is entered we want to return to allow the user
    to enter the next one. But environment variables obviously need to execute
    to completion.

    Add a special case for the execution of environment variables which
    continues when a newline is seen, and add a few tests to check this
    behaviour.

    Note: it's not impossible that this may cause regressions in other areas.
    I can't think of a case but with any change of behaviour with limited test
    coverage there is always a risk. From what I can tell this behaviour has
    been around since at least U-Boot 2011.03, although this pre-dates sandbox
    and I have not tested it on real hardware.

    Reported-by: Wolfgang Denk
    Signed-off-by: Simon Glass

    Simon Glass
     

12 Jun, 2014

1 commit


06 Jun, 2014

1 commit

  • When a simple command like 'false' is provided, hush should return the
    result of that command. However, hush only does this if the
    FLAG_EXIT_FROM_LOOP flag is provided. Without this flag, hush will
    happily execute the empty string command immediate after 'false' and
    then return a success code.

    This behaviour does not seem very useful, and requiring the flag also
    seems wrong, since it means that hush will execute only the first command
    in a sequence.

    Add a check for empty string and fall out of the loop in that case. That
    at least fixes the simple command case. This is a change in behaviour but
    it is unlikely that the old behaviour would be considered correct in any
    case.

    Reported-by: Stefan Herbrechtsmeier
    Signed-off-by: Simon Glass

    Simon Glass
     

30 May, 2014

5 commits