Re: Patch to fix a leak in expand_amble.
On 8/21/16 10:11 PM, Dmitry Goncharov wrote: > Good morning. > > The patch in the attachment fixes a leak in expand_amble. Thanks for the report and fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Patch to fix braces test
On 8/21/16 10:14 PM, Dmitry Goncharov wrote: > Good morning. > > The patch in the attachment fixes the test in braces.c. > > Repace free_array with strvec_dispose. > Remove unused fatal_error and report_error to > eliminate linking failures. Thanks for the report and fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: a patch to fix sh_stat on SunOS
On 8/21/16 10:36 PM, Dmitry Goncharov wrote: >> But why should bash override the semantics that an OS provides for >> /dev/fd, resulting in differing behavior between the shell and other >> utilities with the same pathname argument? > > For the benefit of the user. Currently bash behavior is different from the > native test and ksh on sunos. At least on Solaris, /bin/test is not really a standalone binary, but part of ksh93. Even though the man page references GNU test, it's obvious from running `strings' or `nm' on the binary that it's part of ksh93. > What about a patch that switches to fstat only if such /dev/fd oddity was > determined at configuration time? I'd rather it were done via an explicit switch to configure. I'd look at a patch to do that. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash completion sometimes meshes up my terminal
I am not sure this is a bug but I cannot find an explanation why this
happens. Sometimes when I execute certain commands, and I press the
Tab key while I am typing the command, then after the commands
finishes, the terminal is left in a abnormal state (e.g. terminal echo
is off). This seems to happen when the program in the command has an
associated completion function that performs certain actions, such as
calling grep. Here's a concrete example:
1. Create the file /tmp/test_bashrc with the following contents:
_completion_test() {
grep -q foo /dev/null
#cat /dev/null
return 1
}
complete -F _completion_test yes
complete -F _completion_test find
complete -F _completion_test rlwrap
2. Start a clean bash session with "bash --norc" to ensure that no
external completion rules are loaded.
3. Source /tmp/test_bashrc to load the completion rules from there.
4. Type the following *exactly*: "yes ", followed by a tab, followed
by "| head", followed by enter. That is, type the *exact* sequence of
keys: y e s SPACE TAB | SPACE h e a d ENTER. When the command
completes, the terminal will be messed up (e.g. echo will be off) and
you will need to type something like "stty sane" to fix it.
Now the weird part is that if I remove the grep line from the
completion function, this doesn't happen anymore and everything works
just fine. The problem also happens when I replace the grep line with
something seemingly harmless such as "cat /dev/null".
Here are some alternative commands that exhibit the same problematic behavior:
4a. Type "find /\t| head\n", i.e. f i n d SPACE TAB | SPACE h e a d ENTER.
4b. Type "rlwrap cat" followed by tab and then enter. Then kill the
command with Ctrl-C.
Note, my actual completion function looks more like that:
_completion_test() {
if grep -q "$1" /some/file; then
# put some values in COMPREPLY
else
return 1
fi
}
but that doesn't seem to matter; a mere call to grep (or cat) causes
the problem.
Finally, here's what bashbug has to say about my system:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I./include -I. -I./include -I./lib
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
-DSYS_BASHRC='/etc/bash/bashrc'
-DSYS_BASH_LOGOUT='/etc/bash/bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -DUSE_MKTEMP
-DUSE_MKSTEMP -O2 -march=native -pipe
uname output: Linux XXX 4.4.17 #7 SMP PREEMPT Sat Aug 13 12:58:33 XXX
2016 x86_64 Intel(R) Core(TM) iX-X CPU @ X.XXGHz GenuineIntel
GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 46
Release Status: release
redirection inside a process-substitution
When doing redirection inside a sub-process to a descriptor that is redirected to a file the output of the subshell goes into the file. Now when the same descriptor is again redirected to another descriptor for this whole command-list, the output of the sub-process goes to the other descriptor. Except when the subshell is subject to process-substitution: In this case the outer redirection has no effect to the sub-process. Why is that? Example: rm -f tb.err exec 3>tb.err echo -- 1 -- (echo 1 1>&3) 3>&1 echo tb.err ... cat tb.err echo -- 2 - echo >(echo 2 1>&3) 3>&1 echo tb.err ... cat tb.err echo -- 3 - echo >(echo 3 1>&3) echo tb.err ... cat tb.err Only test 3 should print 3 into tb.err. bash and ksh93 also print into tb.err in test 2, which is inconsistent compared to case 1. What's so special about process-substitution regarding redirection? -Helmut
Syslog output from bash
Hey all:
In my attempts to log commands from bash via syslog, I've come upon a snag.
The output is of the form:
Mmm dd HH:MM:SS hostname -bash: command
This was obtained by uncommenting the define in config-top.h and changing
the call to syslog in bashhist.c as such:
syslog(SYSLOG_FACILITY|SYSLOG_LEVEL, "%s", line);
Problem is, I'd like the output to resemble other syslog messages:
Mmm dd HH:MM:SS hostname bash[pid]: command
And ultimately drop the username in as well. Since only bash is logging in
this format, I'm guessing there is something in the bash source tree
impacting the format, but I can't seem to find it.
As far as the user name, I cobbled a bit of code that will get this for me:
register structure password *pw;
register uid_t uid;
uid=geteuid();
pw=getpwuid(uid);
If(pw) {
return(pw->pw_name); }
else {
//handle the error... }
This works to obtain the username, but seems a little heavy-handed. Is
there something more expedient, by chance?
Thanks in advance,
Rich
Bash bug
When storing the value of code executed in a subshell the return value
is always 0 if the variable is local.
Code example:
A(){
local return_value="$(bash -c "exit 1")"
echo $?
}
function A: returns 0 - even though obviously the return value is 1.
B(){
return_value="$(bash -c "exit 1")"
echo $?
}
function B: returns 1 - as expected, the only difference to function A
being not using a local variable to store the value.
Best regards,
A happy bash user
Re: smart indented HERE docs
I agree something like this would be nice. Especially if it could handle
spaces (in addition to tabs).
My current solution to this problem is not particularly pretty or elegant:
#!/bin/bash
alias CAT_TO_END="I=\"\${I/*\$'\n'/}\" ; alias START=\"perl -ple 's/^\$I//'
<<'\${I}END' ; unalias START\""$'\n'START
shopt -s expand_aliases
if true ; then # Not relevant, except to illustrate a section of the script
that should be indented
I='
' CAT_TO_END
def python_function():
print("Hello World!")
END
fi
To explain:
I put the prefix I want to strip off of each line into $I. In the above
example, the value assigned to $I is split across two lines so that $I contains
an actual indent from a line of the shell script (the indent of the CAT_TO_END
line), which eliminates the need to manually update the value assigned to $I if
I later change the way the shell script is indented. It's too bad that
$BASH_COMMAND doesn't include any leading whitespace, as that would be a better
way to get the actual indent from a line of the shell script.
I then run the CAT_TO_END alias. This alias first removes any characters up to
and including a newline from the value in $I, to handle the case were the
assignment to $I is split across two lines as shown above. ($I should only
contain the relevant prefix, so I strip off the \n and anything before the \n
and only keep the indent from the following line.) CAT_TO_END then defines
another alias (START) and runs it.
The definition and use of the second alias (START) is a hack to allow me to use
the value of $I as part of the here document's delimiter. This allows the END
delimiter to be indented using an arbitrary prefix without requiring me to
hard-code the indent using <<' END'.
The START alias then pipes the here document into perl, which then strips the
value of $I off each line before printing it to STDOUT. After perl exits, the
START alias unaliases itself.
A nice feature of the above is its ability to strip any arbitrary prefix,
including any combination of spaces and tabs. I generally prefer to indent my
scripts using 2 spaces rather than 1 tab, so <<- doesn't really work for me in
general.
Unfortunately, the above will not work if you try to put it in a function, due
to the way bash parses function definitions. However, if you can live without
the convoluted magic that allows the script to dynamically detect its own
indent, you can simplify the above to the following, which will work in a
function:
#!/bin/bash
print_python_code()
{
perl -ple 's/^ //' <<' END'
def python_function():
print("Hello World!")
END
}
print_python_code
In any case, something like <<+END would be much cleaner.
On Sun, Aug 21, 2016 at 11:47:40PM -0400, Derek Schrock wrote:
> I believe this would be a feature request however if this already
> exists directly in bash please let me know.
>
> With <<- you can indent a here-doc such that all tabs will be removed.
> This can be nice for style reasons in your script however to give the
> impression of formatting in the here-doc spaces can be added:
>
>
> cat <<- EOF
> Testing 1 2 3
> Testing 4 5 6
>Testing 7 8 9
> EOF
> ...
>
> Keep in mind the above is prefixed with tabs so with <<- all the prefixed
> tabs are removed.
>
> Would result with:
> Testing 1 2 3
> Testing 4 5 7
> Testing 7 8 9
>
> Would it be possible to add a new character (+) to the here-doc such
> that the number of tabs remove are the number after the closing
> delimiter (EOF in the above example):
>
>
> cat <<+ EOF
> Testing 0 9 8
> Testing 7 6 5
> Testing 4 3 2
> EOF
>
> Note the above here-doc is tabbed out by two but the closing delimiter
> is only tabbed by 1 so only 1 tab is removed.
>
> Would result with:
>
> Testing 0 9 8
> Testing 7 6 5
> Testing 4 3 2
>
> This would allow you to write here-docs inside functions and continue to
> use tabs to maintain proper formatting and not have to use spaces.
>
Re: Bash bug
On Tue, Aug 23, 2016 at 2:34 AM, Weshakie Löwe wrote:
> When storing the value of code executed in a subshell the return value is
> always 0 if the variable is local.
>
> Code example:
>
> A(){
> local return_value="$(bash -c "exit 1")"
> echo $?
> }
>
> function A: returns 0 - even though obviously the return value is 1.
>
``local'' itself is a command. So ``local var=value'' would usually return
0 because it _successfully_ assigns the value the the var. ``local'' would
return non-zero when there's something wrong with the syntax. For example
``local invalid.var.name'' or ``readonly var=1; local var=2''.
>
> B(){
> return_value="$(bash -c "exit 1")"
> echo $?
> }
>
> function B: returns 1 - as expected, the only difference to function A
> being not using a local variable to store the value.
>
Without ``local'', the value of $? would be changed by the $(...) part in
the assignment.
-clark
>
>
>
> Best regards,
>
> A happy bash user
>
>
>
Re: Bash bug
You can do: local var; var=$(...); ... $? No need to make the declaration and assignment at the same time.
Re: Syslog output from bash
Richard Lohman wrote: > Problem is, I'd like the output to resemble other syslog messages: > Mmm dd HH:MM:SS hostname bash[pid]: command > And ultimately drop the username in as well. Since only bash is logging in I suggest using the 'logger' command instead of modifying bash. Normally I am doing things like this: logger -t cmdname "my log message here" But you can get the format you wish with: logger -t "cmdname[$$]" "your log message here" Bob
