Re: 'official function declaration format' doesn't work if alias defined
On Wed, Jan 06, 2016 at 03:49:35PM -0800, Linda Walsh wrote: > I had an alias referring to printf that I wanted to replace > with a function. > > But then ran into problems with the alias taking precedence over the > function. Yup. That's one of the many evils of aliases. They need to be removed (unalias) before you can redefine them as functions. That's why I use "exec bash" to reread .bashrc, not just "source .bashrc". The latter can be confused by previous settings. An "exec bash" always starts clean.
Re: bug: readonly array that is empty causes error (whereas not empty does not)
On 1/7/16 1:54 AM, James Thomas Moon wrote: > I attempted to reproduce the error. The closest error I could reproduce is > slightly different than my original email suggests. > The problem I reproduced below is an undefined variable. To the best of my > recollection, the original error was silent whereas this error, posted > below, is "unbound variable". This may lead to a "behaves as expected" > resolution. A variable is unset until it has been assigned a value. An array variable without any assigned elements is considered unset. This is how bash has behaved at least back to bash-3.2. If there are no positional parameters, "$@" expands to nothing, so it's no different from not specifying any values in a compound assignment. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Feature: Easily remove current command from history
On 1/5/16 8:08 AM, Greg Wooledge wrote:
> imadev:~$ zap me
> bash: zap: command not found
> imadev:~$ history -d -1
> bash: history: -1: history position out of range
> imadev:~$ history -d end
> bash: history: end: history position out of range
>
> Allowing a negative offset to refer to the last (or last minus however
> many) entry would probably satisfy the original request. Semantically,
> there's precedent with negative array indices and negative starting
> positions in ${parameter:offset:length} notation.
Yes, this is a reasonable feature to consider for a future version.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Default time for unmarked history lines
On 7 January 2016 at 20:07, Eduardo A. Bustamante López wrote: > (2) The history should be ordered monotonically (increasing?) > Yes, and it's not at the moment (or wasn't, until I added timestamps to every line in my history), because the lines at the start of the history, with no timestamp, were given the current date and time, and lines at the end of the history, with timestamps, were given the earlier date and time at which they were added to the history. That's why the epoch is better. Also, it's a better clue that the timestamp is being faked.
endpwent protection via HAVE_GETPWENT missing in shell.c:1696
The subject says it all. All other occurrences (in lib/tilde and lib/readlibe) of endpwent are protected with #ifdef HAVE_GETPWENT ... #endif Maybe somebody can add this to the source Cheers, Peter
bind command dies on bad syntax
Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux sc-physb05 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) i686 GNU/Linux Machine Type: i586-pc-linux-gnu Bash Version: 4.3 Patch Level: 30 Release Status: release Description: When I put an extra space in the bind command, it fails silently and corrupts the keyboard map. Lower-case h no longer works. Repeat-By: bind Control-a: forward-search-history
Re: 'official function declaration format' doesn't work if alias defined
Hi,
Am 07.01.2016 um 00:49 schrieb Linda Walsh:
> I had an alias referring to printf that I wanted to replace
> with a function.
>
> instead of using the function declarator
> 'function' (or my alias 'sub'), I remembered that the official
> way was to use:
>
> P () {
> ...
> }
>
> But then ran into problems with the alias taking precedence over the
> function.
>
> Even in the file where the function was defined and exported, I got
> an error in the export statement about "P" not being a function.
> I also tried unaliasing it:
>
> unalias P >& /dev/null || ((1))
>
> export -f P Pe
>
> But still got the "not a function" ... then I realized
> I had used the official, POSIX format for function declarations,
> above, but guess it had silently been changed into
> printf () {
> ...
> }
> by the 'alias'.
Yep. You redefined printf().
> Sure enough, using the old form:
>
> function P () {
> ...
> }
>
> caused "P" to be defined as a function -- so when it was
> unaliased and exported, the export statement found the function.
>
> I am not sure how one would catch a problem like that other than
> by make sure the defined function is never the 1st argument on the line
> (by adding function).
Yep, without the "function" keyword the alias will be used also for replacing
the name of the to be defined function:
$ alias P=foo
$ P () { echo baz; }
$ foo
baz
$ type P
P is aliased to `foo'
$ type foo
foo is a function
foo ()
{
echo baz
}
as it's the first word.
> Seems like using 'function' is safer.
>
> Perhaps the idea of leaving off "function" at the beginning of a function
> isn't such a good practice?
Even if you use it: someone could define an alias named function - and this
stands for all commands.
In some cases it might be possible to check the exit code of `alias P` resp.
`type P` beforehand, or to remove with "unalias -a" all aliases.
-- Reuti
Re: Default time for unmarked history lines
On Thu, Jan 07, 2016 at 08:56:06PM +, Reuben Thomas wrote: [...] > Yes, and it's not at the moment (or wasn't, until I added timestamps to > every line in my history), because the lines at the start of the history, > with no timestamp, were given the current date and time, and lines at the > end of the history, with timestamps, were given the earlier date and time > at which they were added to the history. That's why the epoch is better. > Also, it's a better clue that the timestamp is being faked. I now understand your points. I was playing a bit with the code, and found the piece that initializes time in history entries: dualbus@hp ...src/gnu/bash % git diff diff --git a/lib/readline/history.c b/lib/readline/history.c index 3b8dbc5..2b186e9 100644 --- a/lib/readline/history.c +++ b/lib/readline/history.c @@ -258,7 +258,7 @@ hist_inittime () time_t t; char ts[64], *ret; - t = (time_t) time ((time_t *)0); + t = (time_t) 1; #if defined (HAVE_VSNPRINTF) /* assume snprintf if vsnprintf exists */ snprintf (ts, sizeof (ts) - 1, "X%lu", (unsigned long) t); #else But it seems that the fix is not that simple, since now this happens: dualbus@hp ...src/gnu/bash % cat ~/.bash_history echo 1 #1452197044 echo a; sleep 1 #1452197045 echo b; sleep 1 dualbus@hp ...src/gnu/bash % ./bash -i <<< "HISTTIMEFORMAT='%Y-%m-%dT%H:%M:%S ' history" dualbus@hp:~/local/src/gnu/bash$ HISTTIMEFORMAT='%Y-%m-%dT%H:%M:%S ' history 1 1969-12-31T18:00:01 echo 1 2 2016-01-07T14:04:04 echo a; sleep 1 3 2016-01-07T14:04:05 echo b; sleep 1 4 1969-12-31T18:00:01 HISTTIMEFORMAT='%Y-%m-%dT%H:%M:%S ' history So, it seems that new entries are created with the localtime, unless there's a history comment followed by a timestamp. I'm not sure what changes are needed to adjust this, but I guess that is not a simple fix. BTW, the timestamp = 0 thing is a bug in readline. Since it uses (time_t) 0 as a return value for errors in history_get_time, and later there's code similar to this: t = history_get_time(...) if(t) strftime(...) else strcat(..., "??") It considers 0 as an invalid value. -- Eduardo Bustamante https://dualbus.me/
