On Sat, Feb 5, 2011 at 20:09, Jon Seymour wrote:
> I guess the point is that in versions of bash that do store the
> timestamp in the .bash_history file
To clarify, the timestamp is stored whenever HISTTIMEFORMAT has a
non-null value; the bash version doesn't particularly matter unless
you're sug
On Sat, Feb 5, 2011 at 20:12, Jon Seymour wrote:
> You don't have to do that - the timestamp is encoded in a "comment"
> line between entries. See the example below. One could simply assume
> all lines between two lines beginning with # are part of the one
> entry,
That's what I was saying.
Howe
On Sun, Feb 6, 2011 at 1:07 PM, Michael Witten wrote:
> On Sat, Feb 5, 2011 at 20:02, Michael Witten wrote:
>> So, if you run `history', you'll not only get the commands in the
>> history list, but you'll also get the time at which the commands
>> were last run (formatted according to "$HISTTIMEF
On Sun, Feb 6, 2011 at 1:02 PM, Michael Witten wrote:
> On Sat, Feb 5, 2011 at 19:15, Jon Seymour wrote:
>
> So, if you run `history', you'll not only get the commands in the
> history list, but you'll also get the time at which the commands
> were last run (formatted according to "$HISTTIMEFORMA
On Sat, Feb 5, 2011 at 20:02, Michael Witten wrote:
> So, if you run `history', you'll not only get the commands in the
> history list, but you'll also get the time at which the commands
> were last run (formatted according to "$HISTTIMEFORMAT").
>
> In other words, it's not helpeful in this case.
On Sat, Feb 5, 2011 at 19:15, Jon Seymour wrote:
> Here's the format I see in my history.
>
> #1296950184
> for i in 1 2
> do
> echo $i
> done
> #1296950194
> exit
>
> HISTTIMEFORMAT is:
>
> HISTTIMEFORMAT='[%m.%d.%y] %T '
>
>
> bash -version is:
>
> GNU bash, version 3.2.25(1)-release (i686-red
Here's the format I see in my history.
#1296950184
for i in 1 2
do
echo $i
done
#1296950194
exit
HISTTIMEFORMAT is:
HISTTIMEFORMAT='[%m.%d.%y] %T '
bash -version is:
GNU bash, version 3.2.25(1)-release (i686-redhat-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
jon.
On Sun,
In the version I was using a line that began with # and perhaps a timestamp
separated each entry of the history in a way that in principle preserved
information about the entry boundary even though this information is not used
by bash on the subsequent start.
jon.
On 06/02/2011, at 11:24, Mich
On Sat, 5 Feb 2011, Michael Witten wrote:
On Sat, Feb 5, 2011 at 18:02, Jon Seymour wrote:
The version I tried on Linux 3.2.25 does have a .bash_history
format that could support it, but it still behaved the same way.
How do you mean?
I'm running bash version "4.1.9(2)-release" on GNU/Linux
On Sat, Feb 5, 2011 at 18:02, Jon Seymour wrote:
> The version I tried on Linux 3.2.25 does have a .bash_history
> format that could support it, but it still behaved the same way.
How do you mean?
I'm running bash version "4.1.9(2)-release" on GNU/Linux, and the
resulting history file doesn't se
On Sat, Feb 5, 2011 at 15:56, Slevin McGuigan
wrote:
> I am unsure whether or not this a bug.
>From what I can tell, it's not so much a bug as it is an inadequacy:
When you quit bash, the history is stored very naively in "$HISTFILE";
the history is simply dumped to it line-by-line, and each line
On Sun, Feb 6, 2011 at 10:51 AM, Bob Proulx wrote:
> Slevin McGuigan wrote:
>> I am unsure whether or not this a bug. Anyhow, it is pretty annoying...
>>
>> I use simple multi-line scripts very often in bash and use vi mode
>> to edit them. By using
>> # shopt -s cmdhist
>> # shopt -s lithist
>> I
On Sat, Feb 5, 2011 at 17:51, Bob Proulx wrote:
> Are you thinking that setting shopts should in some way be persistent
> across program invocations? That would be pretty annoying and a
> severe bug if it did.
>
> Are you forgetting to put your desired configuration into ~/.bashrc
> where it is l
Slevin McGuigan wrote:
> I am unsure whether or not this a bug. Anyhow, it is pretty annoying...
>
> I use simple multi-line scripts very often in bash and use vi mode
> to edit them. By using
> # shopt -s cmdhist
> # shopt -s lithist
> I can achive multi-line editing. Which is fine.
>
> But this
Hi,
I am unsure whether or not this a bug. Anyhow, it is pretty annoying...
I use simple multi-line scripts very often in bash and use vi mode to
edit them. By using
# shopt -s cmdhist
# shopt -s lithist
I can achive multi-line editing. Which is fine.
But this ability "breaks" as soon as I cl
On 2/5/11 1:03 PM, Mike Frysinger wrote:
> On Wednesday, February 02, 2011 21:49:38 Chet Ramey wrote:
>> On 2/2/11 6:27 PM, Mike Frysinger wrote:
>>> - lib/glob/smatch.c needs externs.h for mbsmbchar. seems like externs.h
>>> could do with including bashtypes.h/command.h/general.h too since it
>>>
> On Sat, Feb 05, 2011 at 01:58:39PM -0600, Dennis Williamson wrote:
>On Sat, Feb 5, 2011 at 1:35 PM, Roger wrote:
>> When using bash completion on files within local folder, ie. "$ ls f"
>> showing results for files starting with char "f" -- or any char(s) you may
>> specify, results are not prov
On Sat, Feb 5, 2011 at 1:35 PM, Roger wrote:
> When using bash completion on files within local folder, ie. "$ ls f"
> showing results for files starting with char "f" -- or any char(s) you may
> specify, results are not provided in color when bash, terminal and ls are
> configured for using color
On 05 Feb 2011, at 17:09, Andreas Schwab wrote:
>
> Maarten Billemont writes:
>
>> The comment is called a hashbang or shebang. It tells the kernel which
>> program to start. Your script is passed over stdin to the interpreter.
>
> No, it isn't, it's passed as the argument.
>
> Andreas.
O
When using bash completion on files within local folder, ie. "$ ls f"
showing results for files starting with char "f" -- or any char(s) you may
specify, results are not provided in color when bash, terminal and ls are
configured for using color.
I do believe, results for bash completion on files
As far as I know, there is currently no way to display shell-command
key bindings. I would like to propose that bind -x and bind -X without
additional arguments perform this function in a manner parallel to
-[sSvVpP].
On Wednesday, February 02, 2011 21:49:38 Chet Ramey wrote:
> On 2/2/11 6:27 PM, Mike Frysinger wrote:
> > - lib/glob/smatch.c needs externs.h for mbsmbchar. seems like externs.h
> > could do with including bashtypes.h/command.h/general.h too since it
> > needs basic types from all of those.
>
> O
Maarten Billemont writes:
> The comment is called a hashbang or shebang. It tells the kernel which
> program to start. Your script is passed over stdin to the interpreter.
No, it isn't, it's passed as the argument.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58C
ali hagigat writes:
> if (sh -c exit 34) then echo p;fi
> p
> The following condition should be false, because our exit value is
> non-zero.
No, it isn't. You are executing the exit command without an argument,
so it uses the exit status of the last command. Since there was no
On Sat, Feb 5, 2011 at 6:57 AM, ali hagigat wrote:
> #!/bin/sh
> echo ppp
> echo $SHELL
> exit 2200
>
> In the above script i tried to specify /bin/sh as my parser by a
> comment. Is that OK? When I type ./scr2 , i want bash recognize
> /bin/sh as the parser of ./scr2.
>
>
exit only works with
On 05 Feb 2011, at 13:57, ali hagigat wrote:
>
> #!/bin/sh
> echo ppp
> echo $SHELL
> exit 2200
>
> In the above script i tried to specify /bin/sh as my parser by a
> comment. Is that OK? When I type ./scr2 , i want bash recognize
> /bin/sh as the parser of ./scr2.
>
The comment is called a
On 05 Feb 2011, at 13:47, ali hagigat wrote:
>
> if (sh -c exit 34) then echo p;fi
> p
> The following condition should be false, because our exit value is
> non-zero. but 'if' considers the condition as true and executes 'echo'
> command. Why?
>
You are giving -c the argument 'e
On Sat, 5 Feb 2011 16:17:05 +0330
ali hagigat wrote:
> if (sh -c exit 34) then echo p;fi
> p
> The following condition should be false, because our exit value is
> non-zero. but 'if' considers the condition as true and executes 'echo'
> command. Why?
Try
if (sh -c 'exit 34') the
#!/bin/sh
echo ppp
echo $SHELL
exit 2200
In the above script i tried to specify /bin/sh as my parser by a
comment. Is that OK? When I type ./scr2 , i want bash recognize
/bin/sh as the parser of ./scr2.
if (sh -c exit 34) then echo p;fi
p
The following condition should be false, because our exit value is
non-zero. but 'if' considers the condition as true and executes 'echo'
command. Why?
30 matches
Mail list logo
