,7 @@
.\}
.el \{\
.ds ' '
-.ds " ""\" two adjacent quotes and no space before this comment
+.ds " ""\" not usable in macro arguments on AT&T troff (DWB, Solaris 10)
.ds ^ ^
.ds ~ ~
.\}
diff --git a/lib/readline/doc/history.3 b/lib/readline/
before the else when saving to history.
>
> Type into command line (watch out for no-break-spaces added by mail)...
>
>
> if true
> then echo yes
> # comment - required to activate bug
> else echo no
> fi
>
> this works fine! outputting "yes"
istory.
Type into command line (watch out for no-break-spaces added by mail)...
if true
then echo yes
# comment - required to activate bug
else echo no
fi
this works fine! outputting "yes"
But if you look at the history
history|grep i\\f|tail -1
Returning...
830 if true; then echo &qu
On 9/27/2018 5:35 AM, Greg Wooledge wrote:
On Tue, Sep 25, 2018 at 05:17:27PM -0700, L A Walsh wrote:
It struck me as it might be convenient if 'shift' could take an optional
arrayname as an argument. Would that be possible or would it cause some
incompatibility?
The biggest issue
On 9/27/2018 5:42 AM, Dennis Williamson wrote:
[include stdalias]
#[include Types] #if type-checking include Types+line below
lshift () {
(($#)) || return 1
int nshift=1
if [[ $1 =~ ^[0-9]+$ ]]; then nshift=$1; shift;fi
#if ! isArr $1; then echo >&2 "Need arrayname"; return 1; fi
m
On Thu, Sep 27, 2018 at 06:47:33PM +0300, Ilkka Virta wrote:
> Can you make an array whose name even starts with a digit?
No, that's also disallowed. Bash variable names (including arrays) must
begin with a letter or underscore.
On 27.9. 15:35, Greg Wooledge wrote:
Shift already takes one optional argument: the number of items to shift
from the argv list. Adding a second optional argument leads to a quagmire.
Do you put the optional list name first, or do you put the optional number
first? If only one argument is given
On 9/27/18 8:42 AM, Dennis Williamson wrote:
> array_shift=2
> arr=("${arr[@]:$array_shift}")
>
> Done.
This is the simplest and most elegant solution.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CW
On Tue, Sep 25, 2018, 7:17 PM L A Walsh wrote:
> It struck me as it might be convenient if 'shift' could take an optional
> arrayname as an argument. Would that be possible or would it cause some
> incompatibility?
>
> i.e.
>
> > set one two three four five
> > dcl -a ARGV=("$@")
> > shift AR
On Tue, Sep 25, 2018 at 05:17:27PM -0700, L A Walsh wrote:
> It struck me as it might be convenient if 'shift' could take an optional
> arrayname as an argument. Would that be possible or would it cause some
> incompatibility?
The biggest issue here is how you specify the arguments.
Shift alread
It struck me as it might be convenient if 'shift' could take an optional
arrayname as an argument. Would that be possible or would it cause some
incompatibility?
i.e.
set one two three four five
dcl -a ARGV=("$@")
shift ARGV
echo "${ARGV[@]}"
two three four five
shift 2 ARGV
four five
Usually a multi-line command gets added to the history list with
semicolons added in the requisite places, i.e:
$ f() {
> :
> }
$ fc -ln -1
f() { :; }
However, if the final line is a comment, the semicolon is not added,
making the history item an invalid command:
On 7/11/15 4:15 PM, Bill Parker wrote:
> The comment above the line would seem to indicate otherwise:
>
> Here is the comment:
>
>/* Now erase the contents of the current line and undo the effects of the
> rl_accept_line() above. We don't even want t
The comment above the line would seem to indicate otherwise:
Here is the comment:
/* Now erase the contents of the current line and undo the effects of the
rl_accept_line() above. We don't even want to make the text we just
executed available for undoing. */
Bill
On Fri, J
On Thu, Jul 09, 2015 at 01:53:52PM -0700, Bill Parker wrote:
> Hello All,
>
>In reviewing the code at line 990 in bashfile.c, while the
> issue of rl_line_buffer[0] = '\0', would it not be better to
> use memset(rl_line_buffer, '\0', sizeof(rl_line_buffer)) to
> clobber the entire line more ef
Hello All,
In reviewing the code at line 990 in bashfile.c, while the
issue of rl_line_buffer[0] = '\0', would it not be better to
use memset(rl_line_buffer, '\0', sizeof(rl_line_buffer)) to
clobber the entire line more effectively? The patch file
below addresses this issue:
--- bashline.c.or
On 3/26/15 8:28 PM, Christoph Anton Mitterer wrote:
> So why not make a thrid mode like:
> - if cmdhist=on lithist=not-in-file
> which keeps:
> if true; then\n
> echo foo\n
> fi
> in the history
> but writes the serialised "if true; then echo foo ; fi" to the history
> file.
B
On Thu, 2015-03-26 at 16:54 -0400, Chet Ramey wrote:
> The solution cannot be bash-specific; the history library is used by many
> other applications.
One, design-wise ugly, idea:
Couldn't you abuse the history comment char another time for that?
Like consider anything between a ^#[[:
On Thu, 2015-03-26 at 15:21 -0400, Chet Ramey wrote:
> What do you mean "ignore its effect"? You have newlines embedded in
> history entries; what do you plan to do about them?
Well that was just the uneducated idea based on blind assumptions by
*not* having read the code O:-)
AFAIU, both alread
On Thu, 2015-03-26 at 16:26 -0400, Chet Ramey wrote:
> > And b) it seems kinda ugly that one needs to explicitly set a default
> > value that would be set later anyway.
> Maybe.
Okay, keep me tuned if you should plan to actually do that, cause then I
can revise manually setting it :)
> It is wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/26/15 4:51 PM, Eric Blake wrote:
> On 03/26/2015 01:21 PM, Chet Ramey wrote:
>>
>> What do you mean "ignore its effect"? You have newlines embedded
>> in history entries; what do you plan to do about them?
>
> Can't history lines be recorded as
On 03/26/2015 01:21 PM, Chet Ramey wrote:
>
> What do you mean "ignore its effect"? You have newlines embedded in
> history entries; what do you plan to do about them?
Can't history lines be recorded as $'...\n...' so as to be one line per
command, even when the command contained newlines?
--
On 3/25/15 8:06 PM, Christoph Anton Mitterer wrote:
> On Wed, 2015-03-25 at 16:19 -0400, Chet Ramey wrote:
>> When you start bash, and source your .bashrc, the history comment character
>> is not set. You haven't set it in .bashrc, I assume
> Yes, I haven't.
>
>
On 3/25/15 6:03 PM, Christoph Anton Mitterer wrote:
> On Wed, 2015-03-25 at 16:21 -0400, Chet Ramey wrote:
>> https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00042.html
> Maybe I've missed something but that thread basically just discussed the
> same issue without giving a solution, right?
On Wed, 2015-03-25 at 16:19 -0400, Chet Ramey wrote:
> When you start bash, and source your .bashrc, the history comment character
> is not set. You haven't set it in .bashrc, I assume
Yes, I haven't.
> Since that's not set, the lines beginning with
> `#[digit]'
On Wed, 2015-03-25 at 16:21 -0400, Chet Ramey wrote:
> https://lists.gnu.org/archive/html/bug-bash/2011-02/msg00042.html
Maybe I've missed something but that thread basically just discussed the
same issue without giving a solution, right?
I understand you concerns about any format changes, that's
On 3/25/15 3:50 PM, Christoph Anton Mitterer wrote:
> There is the lithist thingy, to preserve newlines in commands which I'd
> quite like.
> But it doesn't work obviously when [re-]storing [from/]to the history
> file.
>
> Would it be possible to have e.g. another option, so that things work
> l
. The history timestamp code depends on the setting of
the history `comment character' -- that's the `#' that it uses to denote
the start of a timestamp entry. The history comment character disables
history expansion for every subsequent character on a line.
When you start bash, and
On Wed, 2015-03-25 at 15:09 -0400, Chet Ramey wrote:
> > I'm having bash4.3 with patches up to including 33. And this time I
> > looked whether Debian added any of it's goodness ;-)
> I'll take a look.
Thanks :)
Speaking of feature-requests and history...
There is the lithist thingy, to preserv
On 3/25/15 3:02 PM, Christoph Anton Mitterer wrote:
> On Wed, 2015-03-25 at 14:48 -0400, Chet Ramey wrote:
>> The history file truncation code already skips lines that look like history
>> timestamps. Look at history.c:history_truncate_file().
> Ah? Hmm was that only recently introduced?
Bash-3.
On Wed, 2015-03-25 at 14:48 -0400, Chet Ramey wrote:
> The history file truncation code already skips lines that look like history
> timestamps. Look at history.c:history_truncate_file().
Ah? Hmm was that only recently introduced?
I'm having bash4.3 with patches up to including 33. And this time
On 3/25/15 2:07 PM, Christoph Anton Mitterer wrote:
> Hey.
>
> When HISTTIMEFORMAT is used the history time comment lines are written
> to HISTFILE.
> Therefore, HISTFILESIZE is effectively only half as large.
>
> Would it be possible to simply not count the history time
Hey.
When HISTTIMEFORMAT is used the history time comment lines are written
to HISTFILE.
Therefore, HISTFILESIZE is effectively only half as large.
Would it be possible to simply not count the history time comment lines
when enforcing HISTFILESIZE?
Cheers,
Chris.
On 7/30/13 7:04 PM, Curtis Doty wrote:
> The above works. Whereas the below fails.
>
> #! /bin/bash -ex
> #
>
> tee >(
> # ain't this nifty
> echo hi there
> )
>
> It burps thusly:
>
> ./foo.sh: line 7: bad substitution: no closing `)' in >(
> # ain't this nifty
> echo
When the comment is inside of a substituted process.
#! /bin/bash -ex
#
tee >(
# this is nifty
echo hi there
)
The above works. Whereas the below fails.
#! /bin/bash -ex
#
tee >(
# ain't this nifty
echo hi there
)
It burps thusly:
./foo.sh:
On 08/16/2012 06:36 PM, Keith Clifford wrote:
>
> some_var=# What I thought was a comment.
^
Not the first byte of a word.
# starts a comment only when it is the first byte of a word.
You can write:
some_var= #Now this is a comment, since there is space between = and #
On Thursday 16 August 2012 20:36:45 Keith Clifford wrote:
> some_var=# What I thought was a comment.
>
> The '#' is eaten by the variable assignment so that some_var gets a null
> value and the rest of the line is not treated like a command.
this is correct (if sometim
Hi,
I first noticed this in a shell script under mingw but tested it in bash
under Linux and it has the same behaviour.
some_var=# What I thought was a comment.
The '#' is eaten by the variable assignment so that some_var gets a null
value and the rest of the line is not trea
> I have a question for you.
> How to comment a paragraph in bash file ?
> I read a lot of documentation and I dont find anything. May be I miss
> It but i need to know.
There isn't a special convention for a paragraph comment.
You can start each line in your paragraph wit
Hello,
I have a question for you.
How to comment a paragraph in bash file ?
I read a lot of documentation and I dont find anything. May be I miss
It but i need to know.
Thanks in advance
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org
40 matches
Mail list logo
