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 14, 2011 at 05:56, Michael Witten mfwit...@gmail.com wrote:
On Sun, Aug 14, 2011 at 04:55, Linda Walsh b...@tlinx.org wrote:
` Michael Witten wrote:
On Sat, Aug 13, 2011 at 23:41, Linda Walsh b...@tlinx.org wrote:
${#${!name}[*]}
bash: ${#${!name}[*]}: bad substitution
On Sat, Aug 13, 2011 at 23:41, Linda Walsh b...@tlinx.org 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
dennistwilliam...@gmail.com wrote:
On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh b...@tlinx.org 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
On Sun, Aug 14, 2011 at 04:55, Linda Walsh b...@tlinx.org wrote:
` Michael Witten wrote:
On Sat, Aug 13, 2011 at 23:41, Linda Walsh b...@tlinx.org wrote:
${#${!name}[*]}
bash: ${#${!name}[*]}: bad substitution
It's probably what you're trying to avoid, but you'll probably have
On Mon, Aug 8, 2011 at 18:44, Linda Walsh b...@tlinx.org 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
On Mon, 8 Aug 2011 21:40:39 +0200, Davide Brini wrote:
On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini dave...@gmx.com 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
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 is what Linda expects... the function definition
On Mon, Jun 13, 2011 at 17:10, Bradley M. Kuhn bk...@ebb.org wrote:
I have all my bash history going back to
2003-10-15 accessible to me.
Why?
On Fri, Jun 3, 2011 at 15:27, Bradley M. Kuhn bk...@ebb.org 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.
On Thu, Jun 2, 2011 at 17:00, Bradley M. Kuhn bk...@ebb.org 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
On Mon, May 30, 2011 at 05:06, Ben Pfaff b...@cs.stanford.edu wrote:
Bradley M. Kuhn bk...@ebb.org 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
On Mon, May 30, 2011 at 02:18, Bradley M. Kuhn bk...@ebb.org 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
On Mon, May 30, 2011 at 03:09, Bradley M. Kuhn bk...@ebb.org 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's objections.
It seems
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 sch...@linux-m68k.org 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 newline or end of
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() **/
shell_getc (1
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() **/
shell_getc (1
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
, 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 mfwit...@gmail.com
---
parse.y |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/parse.y b
+ 2' to `ttranslen + 1'.
Signed-off-by: Michael Witten mfwit...@gmail.com
---
parse.y |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/parse.y b/parse.y
index 55874aa..38c4330 100644
--- a/parse.y
+++ b/parse.y
@@ -4524,7 +4524,7 @@ read_token_word (character
what other code paths in read_token_word()
[currently] do, probably by mistake. :-P
Signed-off-by: Michael Witten mfwit...@gmail.com
---
parse.y |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/parse.y b/parse.y
index b5c94e7..6c095f5 100644
--- a/parse.y
+++ b/parse.y
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
Signed-off-by: Michael Witten mfwit...@gmail.com
---
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
-by: Michael Witten mfwit...@gmail.com
---
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 (character
On Sat, Feb 5, 2011 at 17:51, Bob Proulx b...@proulx.com 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
On Sat, Feb 5, 2011 at 15:56, Slevin McGuigan
slevin.mcgui...@googlemail.com 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
On Sat, Feb 5, 2011 at 20:12, Jon Seymour jon.seym...@gmail.com 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
On Sat, Feb 5, 2011 at 20:09, Jon Seymour jon.seym...@gmail.com 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
On Fri, Sep 24, 2010 at 03:22, Marc Herbert marc.herb...@gmail.com 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 set -e
I was going to note that same caveat in my
31 matches
Mail list logo
