stefco/bsfl

Automatically exported from code.google.com/p/bsfl

bsfl's Issues

Incompatibility with errexit et.al.

bsfl 2.00-beta2 is incompatible with the "holy trinity" of shell programming 
best practices:

set -o errexit
set -o pipefail
set -o nounset

It would be very, very nice to leave to the user the choice wether to use these 
switches or not. Currently I can't include bsfl in any of my scripts for this 
reason alone.

Original issue reported on code.google.com by [email protected] on 13 Jun 2013 at 9:24

Please submit bugs, issues or improvements here!

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

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


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


Please provide any additional information below.

Original issue reported on code.google.com by Louwrentius on 30 Apr 2011 at 4:49

DEBUG not working properly

in version 2.00-beta-2
cmd() doesn't properly test the DEBUG flag.
init() forced DEBUG to "no", which imho doesn't make sense as it works 
differently from all other settings.

--- bsfl
+++ bsfl
@@ -33,7 +33,10 @@
     # Debug mode shows more verbose output to screen and log files.
     # Value: yes or no (y / n)
     #
-    DEBUG=no
+    if ! defined DEBUG
+    then
+        DEBUG=no
+    fi

     #
     # Syslog style log messages
@@ -534,7 +537,7 @@
     if [ "$ERROR" == "0" ]
     then
         msg_ok "$MSG"
-        if [ "$DEBUG" == "1" ]
+        if option_enabled DEBUG
         then
             msg "$RESULT"
         fi

Original issue reported on code.google.com by [email protected] on 13 Jun 2013 at 9:20

license mismatch

On the project homepage, the license is stated to be BSD, while in the header 
of version 2.00-beta-2, it is GPL.
Please pick one...

Additionally, the wording in the header is of dubious legal value. Please use 
the canon wording.

Original issue reported on code.google.com by [email protected] on 13 Jun 2013 at 9:22

bug in functions.sh

In line# 103

https://code.google.com/p/bsfl/source/browse/trunk/functions.sh#103

    SUCCESS | SUCCESS ) 

Should be

    SUCCESS | success ) 

Original issue reported on code.google.com by [email protected] on 25 Jan 2015 at 11:15

Allow cmd function to take a list

The cmd function requires the command string to be quoted.
It would be convenient to just type the command string without quotes. Eg,

      cmd ls -l /dir/to/mystuff 

The change is simple and shouldn't break existing implementations. Eg

    cmd () {

        COMMAND="$@"
        msg "Executing: $COMMAND"
        .
        . continued...
        .

Original issue reported on code.google.com by [email protected] on 13 Sep 2012 at 6:56

DONOTLOG is yes

msg_ always prints DONOTLOG is yes regardless, this looks terrible in output.

What steps will reproduce the problem?
1. Run example.sh


What is the expected output? What do you see instead?
Command: ls -al...                                                 [   OK    ]
Command: ls /blabla...                                                [ FAILED  
]
Command: sleep 2...                                                  [   OK    ]

Instead I see
Command: ls -al...
DONOTLOG is yes                                                     [   OK    ]
Command: ls /blabla...
DONOTLOG is yes                                                     [ FAILED  ]
Command: sleep 2...
DONOTLOG is yes                                                     [   OK    ]

What version of the product are you using? On what operating system?
Latest from SVN , Ubuntu Linux 12.04

Original issue reported on code.google.com by [email protected] on 7 Oct 2012 at 7:03

If TERM is not set you get a lot of spurious errors coming from tput

What steps will reproduce the problem?
1. unset TERM
2. try using msg command
3. note tput errors

What is the expected output? What do you see instead?
The script should do something sane like not try to use tput if the TERM 
environment variable is unset.

What version of the product are you using? On what operating system?
2.00-beta-3 on Linux and OS X

Please provide any additional information below.

See attached patch.

Original issue reported on code.google.com by [email protected] on 24 Jun 2013 at 11:31

REQUEST - Change format of logging to file to be on one line

rather than:

Jul 27 14:04:46 File /etc/passwd exists.
Jul 27 14:04:46 Status =    OK

It would be much more readable if it was all on one line, for example the log 
format my scripts produce are:

INFO:    Jul 27 14:01:01 - log message
ERROR:   Jul 27 14:01:01 - error message
DEBUG:   Jul 27 14:01:01 - debug message
WARNING: Jul 27 14:01:01 - warn message
etc etc

Other than that, top marks, really like what youve done here.

Original issue reported on code.google.com by [email protected] on 27 Jul 2011 at 1:15

typo in functions.sh

On line 153, I read "display_status FAILLURE"
I think it is "FAILURE".

Original issue reported on code.google.com by [email protected] on 21 Dec 2010 at 9:58