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
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 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 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
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 oth
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 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 Wed, Feb 9, 2011 at 08:53, Ingo Molnar wrote:
>
> * Michael Witten wrote:
>
>> On Mon, Feb 7, 2011 at 07:08, Oleg Nesterov wrote:
>> > Now that it is clear what happens, the test-case becomes even more
>> > trivial:
>> >
>> >
The parse_token_word() function (parse.y:4297) has a couple of off-by-one
assignments to the `token' array, which are really 2 manifestations of the
same bug.
These patches first mask the bug by solving the manifestations independently,
and then eradicate the bug by uniformly dismantling the noodl
pinion, this is wrongheaded, but it only requires the change of
one character and it's exactly what other code paths in read_token_word()
[currently] do, probably by mistake. :-P
Signed-off-by: Michael Witten
---
parse.y |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/
_buffer_size,
TOKEN_DEFAULT_GROW_SIZE);
This patch achieves that final result by deflating the `room' value by 1,
from `ttranslen + 2' to `ttranslen + 1'.
Signed-off-by: Michael Witten
---
parse.y |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
dif
t requirement, thereby "masking"
the bug.
In my opinion, this is wrongheaded, but it only requires the change of
one character and it's exactly what other code paths in read_token_word()
[currently] do, probably by mistake. :-P
Signed-off-by: Michael Witten
---
pars
Signed-off-by: Michael Witten
---
parse.y |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/parse.y b/parse.y
index b61c4d0..eaae077 100644
--- a/parse.y
+++ b/parse.y
@@ -4453,7 +4453,7 @@ read_token_word (character)
{
peek_char = shell_getc (1
Signed-off-by: Michael Witten
---
parse.y |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/parse.y b/parse.y
index a12c4d0..b61c4d0 100644
--- a/parse.y
+++ b/parse.y
@@ -4538,17 +4538,13 @@ read_token_word (character)
shell's single-char
ansparent understanding).
Signed-off-by: Michael Witten
---
parse.y | 36 +---
1 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/parse.y b/parse.y
index 38c4330..a12c4d0 100644
--- a/parse.y
+++ b/parse.y
@@ -4382,7 +4382,7 @@ read_token_word (ch
On looking over this patch, I found a number of `bugs' in my description,
but they don't change the conclusions. I should have proofread more carefully.
On Sat, 26 Feb 2011 11:48:06 -0500, Michael Witten wrote:
> /** simulate peek_char and parse_matched_pair() **/
&g
On looking over this patch, I found a number of `bugs' in my description,
but they don't change the conclusions. I should have proofread more carefully.
On Sat, 26 Feb 2011 09:48:06 -0700, Michael Witten wrote:
> /** simulate peek_char and parse_matched_pair() **/
&g
.gnu.org/software/bash/manual/html_node/Shell-Expansions.html#Shell-Expansions
says:
3.5.4 Command Substitution
--
...
... When using the `$(COMMAND)' form, all characters between
the parentheses make up the command; none are treated
specially.
...
If the substitution appears within double quotes, word
splitting and filename expansion are not performed on the
results.
Could somebody please tell me what's going on here?
Sincerely,
Michael Witten
On Sat, Apr 2, 2011 at 08:20, Andreas Schwab wrote:
> Brace expansion.
HAH! :-D
Damn :-/
On Sat, 02 Apr 2011 15:20:23 +0200, Andreas Schwab wrote:
>> Could somebody please tell me what's going on here?
>
> Brace expansion.
>
> $ set -x
> $ echo "$(echo '"' | awk '{sub(/a/,$0)}')"
> ++ echo '"'
> ++ awk 'sub(/a/'
> awk: cmd. line:1: sub(/a/
> awk: cmd. line:1:^ unexpected newli
On Mon, May 30, 2011 at 02:18, Bradley M. Kuhn wrote:
> Chet Ramey wrote on 2009-11-02:
>> Jari Aalto was setting up a git repository of current and older bash
>> versions on savannah. I'll keep him up to date with public versions
>> of bash
>
> Bob Proulx wrote on 2009-11-02:
>>> It looks like i
On Mon, May 30, 2011 at 03:09, Bradley M. Kuhn wrote:
>
> Michael Witten replied a few minutes ago:
>> it is my opinion that all further development should take place through
>> a public, distributed repository such as the one you have created -
>> regardless of Chet&#x
On Mon, May 30, 2011 at 05:06, Ben Pfaff wrote:
> "Bradley M. Kuhn" writes:
>
>> The new repository contains everything that the current
>> Savannah one does, but I put much more effort into making
>> commits fine-grained, rather than merely importing the public
>> releases blindly. (For example
On Thu, Jun 2, 2011 at 17:00, Bradley M. Kuhn wrote:
> I'd suggest that we keep the master branch only to track the history of
> releases and officially released patches as Chet posts them, and then we
> can use separate branches for individual developers who want to use Git.
> What do you think o
>On Thu, Jun 2, 2011 at 17:00, Bradley M. Kuhn wrote:
>> I'd suggest that we keep the master branch only to track the history of
>> releases and officially released patches as Chet posts them, and then we
>> can use separate branches for individual developers who want to use Git.
>> What do you th
On Fri, Jun 3, 2011 at 15:27, Bradley M. Kuhn wrote:
> Sorry, I was imprecise in my wording in my email yesterday. By "use
> separate branches for individual developers", I meant that "branches
> would be created for those developers who wanted to develop publicly in
> a Git repository".
Such de
On Mon, Jun 13, 2011 at 17:10, Bradley M. Kuhn wrote:
> I have all my bash history going back to
> 2003-10-15 accessible to me.
Why?
On Mon, Aug 8, 2011 at 18:44, Linda Walsh wrote:
>
> I was testing functions in my shell, I would cut/paste,
> thing is, with each past, I'd get my dir listed (sometimes multiple times)
> on each line entered.
>
> Now I have:
> shopt:
> no_empty_cmd_completion on
>
> i.e. it's not supposed to exp
On Mon, 8 Aug 2011 21:40:39 +0200, Davide Brini wrote:
> On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini wrote:
>
>> In fact, you could do the same thing with
>>
>> foo() { # hit tab here
>>
>> and I'm sure you wouldn't consider that an empty line.
>
> I have to take that back: it looks like
On Mon, 08 Aug 2011 15:56:30 -0700, Linda Walsh wrote:
> Michael Witten wrote:
>>
>> In any case, even if `no_empty_cmd_completion' were to behave as Linda
>> expected, her tabs would still get eaten when pasted on the interactive
>> command line.
>
> Which
On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
> ${#${!name}[*]}
> bash: ${#${!name}[*]}: bad substitution
It's probably what you're trying to avoid, but you'll probably have to
construct and then eval the right code by hand:
$(eval "echo \${#$name[*]}")
On Sun, Aug 14, 2011 at 00:49, Dennis Williamson
wrote:
> On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
>>
>>
>>
>> I want to have an array of 'names'.
>>
>> given a name, "X", I had a prefix, _p_, so have _p_X,
>> I want to access / manipulate it as an array.
>>
>> so given I pass in a na
On Sun, Aug 14, 2011 at 04:55, Linda Walsh wrote:
>
>
>
> ` Michael Witten wrote:
>>
>> On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
>>
>>>
>>> ${#${!name}[*]}
>>> bash: ${#${!name}[*]}: bad substitution
>>>
>>
&
On Sun, Aug 14, 2011 at 05:56, Michael Witten wrote:
> On Sun, Aug 14, 2011 at 04:55, Linda Walsh wrote:
>>
>>
>>
>> ` Michael Witten wrote:
>>>
>>> On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
>>>
>>>>
>>>>
On Mon, Sep 12, 2011 at 14:19, Roger wrote:
>> On Mon, Sep 12, 2011 at 08:36:07AM -0400, Greg Wooledge wrote:
>>On Sun, Sep 11, 2011 at 11:23:48PM -0800, Roger wrote:
>>> When using GNU Screen (or other terminal multiplexer), I noticed the
>>> terminal
>>> multiplexer never gives each bash shell
t', which executes `source file2' in the current shell context,
which creates the variable `v1' in the current shell context, but
creates the variables `v2' and `v3' local to the function being
executed in the current shell context, so that by the echo statement,
only `v1' is defined.
Sincerely,
Michael Witten
On Sun, Aug 15, 2010 at 19:55, Mike Frysinger wrote:
> On Sun, Aug 15, 2010 at 8:47 PM, Peng Yu wrote:
>> cat file.txt | sqlite3 main.db <
> you only get 1 stdin ... either via the pipe or the heredoc. give
> everything you want to the first cat and worry about sqlite only
> consuming the pipe.
>
On Mon, Aug 23, 2010 at 16:40, Eric Blake wrote:
> On 08/23/2010 03:29 PM, Peng Yu wrote:
>>
>> Hi,
>>
>> I'm wondering if there is a widely accepted coding style of bash scripts.
>>
>> lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf
>>
>> I've seen the following style. Which is one is more wide
On Fri, Sep 24, 2010 at 03:22, Marc Herbert wrote:
>> On Thu, Sep 23, 2010 at 04:38:42PM -0500, Michael Witten wrote:
>>> This is also possible:
>>>
>>> [ -f "$file" ] && do_something
>
> Note that this style is not compatible with se
39 matches
Mail list logo
