Re: Default time for unmarked history lines
On 8 January 2016 at 04:21, Eduardo A. Bustamante López wrote: > > I now understand your points. > Thanks very much for taking a look at this. > 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. > I'm puzzled by this. What do you mean by "unless there's a history comment followed by a timestamp"? The history file you dump ends with a command, not a timestamp. I am guessing that the bash you then invoke does not have HISTTIMEFORMAT set in its environment, so no timestamp is added for the last line. > BTW, the timestamp = 0 thing is a bug in readline. Aha! Thanks. -- http://rrt.sc3d.org
Re: bind command dies on bad syntax
On 1/7/16 9:16 AM, Andrew Kurn wrote: > 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 OK, let's unpack this. First, this is two separate key bindings, since word splitting results in two arguments. The first one easy: it binds C-a to nothing. You specify a key binding, but no command to bind it to. The second is a little more confusing. The key name to be bound is whatever appears following the final hyphen (in this case, `history'). (The strings before the final hyphen are assumed to be modifiers, but unknown modifiers are ignored.) That string doesn't match any of the key names readline treats specially, so it assumes you want to bind the first character of the string (`h'). Since you don't provide a readline command to bind to, it gets bound to nothing. The reasons for this kind of `forgiving' key binding syntax have been lost over the last 27 years. I'll see what I can do to improve error reporting here. -- ``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: aliases v. functions; command extension? (-f & -F)?
For what it's worth, It might be useful to have something like
'command' that (or maybe a flag to 'command', like "-f & -F" that would
search for functions for the 'command' either before ("-f")
the PATH search, or after ("-F"), for the case of the command not
being found in the PATH.
Reuti wrote:
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.
---
My scripts are designed to assist. I rarely need to design them to be
"invulnerable" against malicious actions. I usually define an alias or,
when
I want "elaboration", a function, that uses '$(type -P cmd)' as the path
(elaboration = things like handling error conditions or running command as
root).
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.
"unalias P 2>&- || ((1))" seemed best for this case.
"unalias -a" would usually not be the best thing to do, in my
environment, as aliases are usually more helpful than not. There are
several places in my shell
scripts where functions don't work (like in this case). Seems like the best
solution, usually, is to define your own alias in the script and use
that. The down-side of that is if you later want to introduce a
function in place of the
alias -- I guess _that_'s a good reason to use an include file like:
"include stdalias"
so all of one's aliases are in one place. Although that requires that
an 'include' command be available and defined going into a script (I use a
function to define that in my system "/etc/bash_env").
=
Greg Wooledge wrote:
Yup. That's one of the many evils of aliases. They need to be removed
(unalias) before you can redefine them as functions.
Not if you include a prefix indicating it is a function (e.g.
"function").
It was my trying to use 'recommended' format that got me in trouble in this
case.
I usually define my own alias, "sub", for function. Besides being
shorter,
it also would seem to protect against this type of problem and is
another case
where a function can't do the job of an alias.
-l
Re: aliases v. functions; command extension? (-f & -F)?
hello Linda,
On Fri, Jan 8, 2016 at 9:14 PM, Linda Walsh wrote:
>
> For what it's worth, It might be useful to have something like
> 'command' [..]
that would be useful, a keyword like:
function p params;
that always calls function no matter what. maybe best would be to have
something like:
run -f fname params # if (f=find_function("fname"))!=null executes f else error
run -c cname params # same as command cname params
same with alias?
maybe together with some general "whatis" mechanism, that would give
information about a symbol, its definitions, and the order in which
they are to be resolved.
sincerely,
pg
Re: Feature: Easily remove current command from history
On Thu, Jan 7, 2016 at 9:32 PM, Chet Ramey wrote:
> 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
>> [..]
>
> Yes, this is a reasonable feature to consider for a future version.
I cant believe we do not have it already.
Maybe I am missing something, please review the following (works for
me; devel at 6f82653c5ef09aeeeba4376a1c65ce86c3605c00, also in
attachment in case of formatting problems):
diff --git a/builtins/history.def b/builtins/history.def
index dfa4fb7..4c938af 100644
--- a/builtins/history.def
+++ b/builtins/history.def
@@ -107,6 +107,8 @@ history_builtin (list)
int flags, opt, result, old_history_lines, obase;
char *filename, *delete_arg;
intmax_t delete_offset;
+ int is_legal_number = 0;
+ int index = 0;
flags = 0;
reset_internal_getopt ();
@@ -180,14 +182,34 @@ history_builtin (list)
#endif
else if (flags & DFLAG)
{
- if ((legal_number (delete_arg, &delete_offset) == 0)
- || (delete_offset < history_base)
+ is_legal_number = legal_number (delete_arg, &delete_offset);
+ if (is_legal_number == 0)
+ {
+ sh_erange (delete_arg, _("history position"));
+ return (EXECUTION_FAILURE);
+ }
+ if ((delete_arg[0] == '-') && (delete_offset < 0))
+ {
+ if ((index = history_length + delete_offset) >= 0)
+ {
+ opt = index + 1;
+ }
+ else
+ {
+ sh_erange (delete_arg, _("history position"));
+ return (EXECUTION_FAILURE);
+ }
+ }
+ else
+ {
+ if ((delete_offset < history_base)
|| (delete_offset > (history_base + history_length)))
{
sh_erange (delete_arg, _("history position"));
return (EXECUTION_FAILURE);
}
opt = delete_offset;
+ }
result = bash_delete_histent (opt - history_base);
/* Since remove_history changes history_length, this can happen if
we delete the last history entry. */
sincerely,
pg
diff --git a/builtins/history.def b/builtins/history.def
index dfa4fb7..4c938af 100644
--- a/builtins/history.def
+++ b/builtins/history.def
@@ -107,6 +107,8 @@ history_builtin (list)
int flags, opt, result, old_history_lines, obase;
char *filename, *delete_arg;
intmax_t delete_offset;
+ int is_legal_number = 0;
+ int index = 0;
flags = 0;
reset_internal_getopt ();
@@ -180,14 +182,34 @@ history_builtin (list)
#endif
else if (flags & DFLAG)
{
- if ((legal_number (delete_arg, &delete_offset) == 0)
- || (delete_offset < history_base)
+ is_legal_number = legal_number (delete_arg, &delete_offset);
+ if (is_legal_number == 0)
+ {
+ sh_erange (delete_arg, _("history position"));
+ return (EXECUTION_FAILURE);
+ }
+ if ((delete_arg[0] == '-') && (delete_offset < 0))
+ {
+ if ((index = history_length + delete_offset) >= 0)
+ {
+ opt = index + 1;
+ }
+ else
+ {
+ sh_erange (delete_arg, _("history position"));
+ return (EXECUTION_FAILURE);
+ }
+ }
+ else
+ {
+ if ((delete_offset < history_base)
|| (delete_offset > (history_base + history_length)))
{
sh_erange (delete_arg, _("history position"));
return (EXECUTION_FAILURE);
}
opt = delete_offset;
+ }
result = bash_delete_histent (opt - history_base);
/* Since remove_history changes history_length, this can happen if
we delete the last history entry. */
