oh wow, this is nice:
#define get_job_by_jid(ind) (jobs[(ind)])
155 if ((job == NO_JOB) || jobs == 0 || get_job_by_jid (job) == 0)
definitely this if needs looking into.
cheers,
pg
On 11 Jul 2018, at 15:41, Simon Wörner wrote:
> Dear all,
> The following crash was found by a modi
hello,
I wanted to play around with this idea, and see how it works. Quick and dirty
patch (against devel@c181950a89c0f0ca4a3ae2480b783da2f7de9565) is attached.
Just modified parser and hardcoded tempfile /tmp/v_save.bash.temp. result:
bash-5.0$ echo 'hello a' >>> a; echo $a
hello a
If you
On 27 Jun 2018, at 14:57, Chet Ramey wrote:
> On 6/27/18 6:59 AM, Piotr Grzybowski wrote:
>
>> +function_newline_list: '(' ')' | function_newline_list '\n'
>> + ;
>> +
>
> This would appear to allow constructs like
>
>
Hey,
I case anyone noticed, in the current devel there is shift/reduce conflict
reported by bison. Those usually are a symptom of not fully controlled grammar,
and I would like to think that we are in full control over parse.y.
It is caused by function_def rule, namely the combination of '(' a
ehlo,
I kind of like it. It also bothered me from time to time, not in the case of
lmod though.
I enclose the patch. Note that it does not work with depth of functions, since
it is not the way xtrace subsystem prints the levels. Different patch is needed
if you want to control function frames
Hi,
maybe I do not fully follow your example, but wouldn't you instead of:
time D="${C//\[+([0-9])\]=}" # rm '[]='
want:
time D="${C//\[[0-9]*\]=}" # rm '[]='
your example copies a lot to D and thats what takes time, I guess.
cheers,
pg
On 18
hi,
this is recurring cd story:
https://lists.gnu.org/archive/html/bug-bash/2016-04/msg00038.html
pg
On 14 Sep 2016, at 12:01, idal...@home.idallen.ca wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation C
On 23 Aug 2016, at 08:08, Bob Proulx wrote:
> Richard Lohman wrote:
>> Problem is, I'd like the output to resemble other syslog messages:
>> Mmm dd HH:MM:SS hostname bash[pid]: command
>> And ultimately drop the username in as well. Since only bash is logging in
>
> I suggest using the 'logger'
Hi,
cannot replicate that with 4.4.0(18)-beta2 (latest devel at
a4eef1991c25c9d1c55f777952cd522c762c6fc3)
I would assume it has been fixed.
cheers,
pg
On 13 Aug 2016, at 12:12, psko...@gmail.com wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
>
Hi,
amending the previous approach; please find the attached patch: the global
namerefs are followed, and resolved in the function scope. It works as follows:
bash-4.4$ typeset -n v=w; typeset -n w=x; typeset -n x=v; x=4
bash: warning: x: circular name reference.
bash-4.4$ declare -n ref="HOME
Hi,
since we already allow circular refs in the variable_context, the below
answers your request. It means: in the function scope the name references to
existing global variables will be correctly resolved. Please note that using
find_global_variable in global_variable=find_global_variable(new
yeah, thats why I asked about version, but never mind that, Laszlo: I would
like to see :
cat /usr/lib/sysctl.d/50-default.conf | grep fs
pg
On 28 Jul 2016, at 20:56, Charles Daffern wrote:
> As far as I'm aware, the inability to use symlinks owned by another user
> in a sticky directory i
ser who created the symlink. From my limited knowledge, the sticky bit
> is supposed to prevent file and directory removal, not status query. Am I
> missing something?
>
> Thanks.
>
>
>
> On Thu, 2016-07-28 at 19:12 +0200, Piotr Grzybowski wrote:
>> hi,
>
hi,
this, as well as the issue from the link you have provided, is nonexistent on
bash-4.4-testing at a4eef1991c25c9d1c55f777952cd522c762c6fc3 I would consider
it fixed.
cheers,
pg
On 15 Jul 2016, at 15:36, psko...@gmail.com wrote:
> Configuration Information [Automatically generated, do not
hi,
this is nonexistent in current devel at
814e1ff513ceca5d535b92f6c8dd9af7554fe83e so I would assume it fixed.
are you able to grab and build from devel branch to confirm?
cheers,
pg
On 30 May 2016, at 12:56, Sergey Tselikh wrote:
> Configuration Information [Automatically generated, do n
On 26 May 2016, at 21:03, Chet Ramey wrote:
> On 4/27/16 3:26 PM, Grisha Levit wrote:
>> |declare -n name=value|, when |name| is already a nameref, shows the
>> following presumably inconsistent behavior:
>
> There's a fairly compelling argument -- and I think Piotr made it -- that
> `declare -n'
hi,
there are two problems: not checking NULL returned by bind_variable, and not
allowing to enter valid_nameref_value.
Since bind_variable can return NULL, that should be checked everywhere.
Also NULL and empty strings are not valid nameref values, so the check should
be added in valid_namer
On 13 May 2016, at 23:31, Grisha Levit wrote:
> All the behavior inside functions now seems consistent with what is in the
> docs. But the behavior at global scope still seems strange (sorry if this is
> still a WIP):
> Each of the following produces different results in global scope and inside
yeah, started yesterday, seems like a reaource allocation problem, I would
avoid clones, if possible, and fetch only certain branches. if you already
have a piece of repo that is.
usually pulls work after a couple of tries.
pg
El 13/05/2016 23:41, "Mike Frysinger" escribió:
> On 13 May 2016 15:4
hi,
there are two issues here, small regressions.
I think in tmpenv we should create the variable unconditionally (concerning
the namerefs), and should not follow the namerefs on checking if the variable
exists:
diff --git a/variables.c b/variables.c
index 1877b17..f149b66 100644
--- a/variab
On 5 May 2016, at 13:48, Eduardo A. Bustamante López wrote:
> I'm able to replicate with the master branch. [..]
yes, it appeared on the master with:
commit ac50fbac377e32b98d2de396f016ea81e8ee9961
Date: Wed Feb 26 09:36:43 2014 -0500
Bash-4.3 distribution sources and documentation
at t
On 5 May 2016, at 20:08, Piotr Grzybowski wrote:
> [..]
> Currently the design indicates: :p applies to the whole line.
As Dean just has pointed out to me, this sentence is obviously wrong. it
should be:
Currently the design indicates: the last :p applies to the whole line, the
infor
Hey,
confirmed, this is what happens by construction.
this one is going to be tricky, expansion happens on the shell line, way
before it comes to execution. I do not see reparsing again at execute_command
even if we had means, which we dont, to store the information from history
expansion to
hi,
I cannot replicate it in anyway on mac os x or linux.
Could you please define "sometimes", and supply the exact version of bash that
shows this behavior, and the version you refer to as "my old bash"? I have a
distinct feeling that it is something different than my old bash.
cheers,
pg
guess.
pg
On 5 May 2016, at 09:46, Piotr Grzybowski wrote:
>
> ok, so Dan wants this patch.
> I took a look at your script, there are two cases it addresses: exporting
> nameref and doing it from inside the function scope, I applied both patches:
>
> nameref masking
ok, so Dan wants this patch.
I took a look at your script, there are two cases it addresses: exporting
nameref and doing it from inside the function scope, I applied both patches:
nameref masking in scope:
https://lists.gnu.org/archive/html/bug-bash/2016-05/msg00012.html
exporting namerefs:
h
I can understand this, but perhaps this discussion is too general? in this
particular case there is no point in the assignment. Unless you can convince me
there is?
pg
On 5 May 2016, at 00:31, Dan Douglas wrote:
> ...Also remember it isn't feasible to actually validate a "name" in a
> script
On 4 May 2016, at 17:51, Chet Ramey wrote:
> The issue I'm thinking about currently is whether or not to allow nameref
> variables to have numeric (integer) values. bash-4.3 didn't allow those
> values to be expanded, but allowed them to be assigned. It doesn't seem
> harmful to change the erro
Hey,
after another discussion with Grisha, and following one of his remarks, I
kindly request your opinion on the attached patch (like: bad, not needed,
already done, weak as it stands, harmful, etc.). It addresses the exporting of
identifiers with have nameref attribute set.
at the moment we
Hi,
I hope the attached patch does not break to much; it addresses the masking:
> declare -nt r=a; f() { declare a; declare -n r=a; declare -p a r; }; f
as per Grisha's report; it tries to enlighten make_local_variable to the
existence of nameref by returning existing local nameref in scope (d
Hi,
On 2 May 2016, at 10:26, Dan Douglas wrote:
> FWIW, something like this works currently. This pattern is useful in a
> bunch of situations where the shell wants to assign to a fixed
> variable name. (getopts being another). [..]
thanks for the hint, of course I like it with the patch better
after discussion with Grisha, the reason to different behaviour between:
f() { declare -n ref=var; declare -n ref; declare -p ref; }; f
and
f() { local var; declare -n ref=var; declare -n ref; declare -p ref; }; f
is:
in function context declare built-in always calls make_local_variable. thi
On 30 Apr 2016, at 22:24, Grisha Levit wrote:
> I just re-built bash-20160415 snapshot and am observing the same behavior.
> To clarify, the first case is the unexpected one -- shouldn't `declare -n
> ref=var; declare -n ref' be a no-op, no matter if $var is set or not? It is
> a no-op when i
hi,
this one is not present in current devel, I would consider it fixed already.
pg
On 29 Apr 2016, at 18:50, Grisha Levit wrote:
> I should note also that the behavior when inside a function matches exactly
> what the manual says. It’s the global namerefs that have this unexpected
> behavi
On 29 Apr 2016, at 03:49, Grisha Levit wrote:
> There is also an issue when doing something like `declare -n r=a' in a
> function if the same has been done in a higher scope. Instead of creating a
> new variable r in the function's scope, it modifies the local `a' to be a
> self-referencing n
readonly variable
c. we can forbid the assignment:
# ref=
d. try to detect the "nameref loop"
2.b-d seem illogical to me, and against the decision behind introducing the
namerefs.
cheers,
pg
On 28 Apr 2016, at 02:36, Grisha Levit wrote:
>
> On Wed, Ap
On 28 Apr 2016, at 02:36, Grisha Levit wrote:
>
> On Wed, Apr 27, 2016 at 6:47 PM, Piotr Grzybowski wrote:
> + if (v == 0 && onref || ( onref && !legal_identifier(value)))
>
> Shouldn't this (and the other patch) check valid_array_reference as w
legal identifiers during declare -n and in
later assignments to the nameref variable.
cheers,
pg
On 28 Apr 2016, at 00:47, Piotr Grzybowski wrote:
>
> a short summary:
>
> 1. there is a real bug reported here: allowing namref on illegal identifiers,
> if we assume that the value of t
a short summary:
1. there is a real bug reported here: allowing namref on illegal identifiers,
if we assume that the value of the variable that has nameref attribute is the
name of the variable it refers to, then we have to require that declare -n a=b
anly allows legal identifiers for b:
di
this one does not seem like a bug to me, rather a decision made by the author:
to interpret "on the variable" from this:
"All references, assignments, and attribute modifications to name, except for
changing the -n attribute itself, are performed on the variable referenced by
name’s value."
On 27 Apr 2016, at 21:49, Eduardo A. Bustamante López wrote:
>
> Actually, this seems to be a special case, just because '5' is an invalid
> variable name. But the problem still exists:
>
> | dualbus@hp ...src/gnu/bash % ./bash -c 'declare -r RO=x; r=$RO; declare -n
> r; x=y; declare -n RO; R
wrote:
> On Wed, Apr 27, 2016 at 7:37 AM, Piotr Grzybowski wrote:
>
>
>
> It seems to me that creating the reference should be allowed, but the access
> to the referenced variable should honor its attributes.
>
>
> Once you convert the variable to a reference, y
On 27 Apr 2016, at 20:43, Eduardo A. Bustamante López wrote:
> The attached patch seems to take care of at least these two cases: [..]
> But I think Chet already considered this, given that the check in declare.def
> was '#if 0'ed out.
maybe for a reason, after your patch:
bash-4.4$ declare -n
On 27 Apr 2016, at 20:43, Eduardo A. Bustamante López wrote:
> The attached patch seems to take care of at least these two cases: [..]
your patch also adresses the original Grisha's report:
declare -r T=5; ref=$T; declare -n ref; ref=10; declare -n T;
cheers,
pg
Hi,
On 27 Apr 2016, at 14:41, Grisha Levit wrote:
> Once you convert the variable to a reference, you can control its value by
> modifying the value of a different variable with the name that corresponds to
> the value of the readonly variable, so “access to the referenced variable
> should ho
On 25 Apr 2016, at 22:57, Grisha Levit wrote:
> A related issue is with adding the nameref attribute to a readonly variable.
> Not sure if that should be allowed, as it can be used to change the meaning
> of the variable [..]
It seems to me that creating the reference should be allowed, but th
On 26 Apr 2016, at 21:03, Grisha Levit wrote:
> This behavior seems very strange. This example is with $@ but it seems the
> same for ${array[@]}
>
> The manual says for ${parameter:-word}:
>
> > If parameter is unset or null, the expansion of word is substituted.
>
> In this case, $@ is exp
Hi Grisha,
confirmed.
I think this one fixes it:
diff --git a/variables.c b/variables.c
index 69ed170..9eeda46 100644
--- a/variables.c
+++ b/variables.c
@@ -2636,9 +2636,14 @@ bind_variable_internal (name, value, table, hflags,
aflags)
#if defined (ARRAY_VARS)
/* declare -n foo=x[2] *
Hi,
It is a history_tokenize_word problem, please consider the following:
diff --git a/lib/readline/histexpand.c b/lib/readline/histexpand.c
index fdecebc..ca4b4c8 100644
--- a/lib/readline/histexpand.c
+++ b/lib/readline/histexpand.c
@@ -1447,7 +1447,8 @@ history_tokenize_word (string, ind)
hi,
yes, this happens here:
lib/readline/histexpand.c:1406
result[offset++] = ' ';
pg
On 22 Apr 2016, at 01:28, idal...@home.idallen.ca wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFL
hi,
I cannot replicate this in anyway, I just created 1024 functions and then ran
unset -f in a while [ 1 ]; do done; loop on the very same bash version but on
earlier version of darwin, and everything seems fine.
Could you please provide the exact code that triggers the problem, together
wit
On 21 Apr 2016, at 09:36, Grisha Levit wrote:
> A few issues inspired by the coproc proposal in this thread:
> http://lists.gnu.org/archive/html/bug-bash/2016-04/msg00050.html
>
> 1. coproc unsets readonly NAME after the process completes [..]
> 2. Segfault if NAME is an existing associative ar
On Tue, Apr 19, 2016 at 7:02 PM, Chet Ramey wrote:
> On 4/16/16 8:13 AM, Piotr Grzybowski wrote:
> >
> [..]
>
> > - expand the name given to coproc
>
> I'll consider this for a future version of bash.
>
>
thanks. maybe someone else finds it useful
Hi,
for some time I wanted to do:
WORKERS_COUNT=8;
for((i=0;i<${WORKERS_COUNT};i++)); do
coproc worker$i { worker_code; };
done;
and since lately I got an actual real, production, case where I had to run
given number of workers and issue jobs for them (exactly: run N encoders in
M co-processe
Hello!
I firmly believe that the attached patch fixes the problem at hand; what
it breaks I have no idea. Kindly requesting a review.
cheers,
pg
P.S.
it also fixes others of the similar type, e.g.:
x=$(case 1 in 1) echo 1;; esac; case 2 in 2) echo 2;; esac;)
echo $x
P.P.S.
vim :syntax notic
Hello Christian,
Hi all,
confirmed. this is due to the fact, that the second case does not
get tflags |= LEX_INCASE; in parse_comsub which returns prematurely.
when I give up on trying to fix that I will let you know :)
cheers,
pg
On Tue, Mar 29, 2016 at 7:43 PM, Christian Franke <
christian.
hi,
I think the logic behind variables.c:723 get_bash_name is in this
case: put into BASH whatever valid command given to exec -a . E.g.: if
you put exec -a /bin/ksh /bin/bash and /bin/ksh exists and is
executable it will be seen in BASH variable.
sincerely,
pg
On Tue, Feb 9, 2016 at 1:09 AM
hello,
it is no longer existent in the recent devel:
GNU bash, version 4.4.0(3)-rc1 (i686-pc-linux-gnu)
while it is reproducible in the version you file the report for.
sincerely,
pg
On Fri, Feb 5, 2016 at 10:23 AM, wapiflapi wrote:
> Configuration Information [Automatically generated, do
hi,
On Sat, Jan 16, 2016 at 8:28 PM, Adam Danischewski
wrote:
> ..
> Yet if we look for the null byte:
> $> while IFS= read -r -d'' a; do echo "got $a"; done < <(find . -type f
> -print0)
>returns nothing
this is because it is the same as:
read -r -d a;
I think there
hey,
I am quite sure it happens here (devel branch, at
6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
execute_cmd.c +5115:
if ((cmdflags & CMD_STDIN_REDIR) &&
pipe_in == NO_PIPE &&
(stdin_redirects (redirects) == 0))
async_redirect_stdin ();
but after reading the comments some 3.5k lin
On Sat, Jan 9, 2016 at 8:12 PM, Reuti wrote:
>
> AFAICS putting the name in quotes (single or double) will prefer the function
> over the alias, but it will fall back to a command if there is no function.
>
> 'P' params
if Linda is ok with it, I will not argue, I would prefer an explicit
way to
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 o
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:
hello,
I cannot reproduce it in anyway on mac os x86_64 with any version
after 4.2, but I see your output on i686 linux with 4.3 and 4.4. Seems
system dependent, and also: it is enough to change line 10 to:
/bin/echo final
or
stdbuf -o0 -i0 -e0 echo final
to get expected results. I wonder if
On Mon, Jan 4, 2016 at 9:19 PM, Victor Porton wrote:
> It is important for security:
>
> It should be easy to remove lines with passwords and potentially harmful
> commands (like sudo with rm).
never put your passwords in plain text in commands, thats important
for security. If, for some reasons,
On Sun, Jan 3, 2016 at 8:24 AM, Eduardo A. Bustamante López
wrote:
> On Sat, Jan 02, 2016 at 03:08:54PM +0200, Joey Geralnik wrote:
>> I have found an easily reproducible bug in bash that causes it to crash and
>> have attached a fix.
>
> I think this was already reported [..]
> And I think the fi
hi,
nice one. reproducible on:
#bash -version
GNU bash, version 4.3.42(1)-release (x86_64-apple-darwin10.8.0)
not reproducible on the same version on i686-pc-linux-gnu
pg
On Sat, Jan 2, 2016 at 2:08 PM, Joey Geralnik wrote:
> I have found an easily reproducible bug in bash that causes it to
hi,
I am not sure if autocd is supposed and expected to run just anything
called "cd", but for what its worth, the following patch does what you
want.
diff --git a/execute_cmd.c b/execute_cmd.c
index daa08c2..9a29da0 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -4297,6 +4297,11 @@ run_built
On Wed, Dec 23, 2015 at 2:05 PM, Greg Wooledge wrote:
> [..]
> On the one hand, we have draconian control-freak admins who want to
> impose their policy on every user unconditionally, through things
> like /etc/bash.bashrc (or /etc/bashrc or however the vendor chooses
> to spell it). And now appa
On Wed, Dec 23, 2015 at 12:29 PM, konsolebox wrote:
> On Wed, Dec 23, 2015 at 2:49 PM, James Thomas Moon wrote:
>> In my case, I would like to preserve a copy of all passed arguments: [..]
> I can't reproduce this. My script always returns 0.
same here. cant reproduce on any version.
pg
Hi.
I have had a need to know the number of the client port after successful
exec 4<>/dev/tcp/${host}/${port}
[..]
The attached patch stores the local, client port in the variable
LOCALPORT. Would you accept this new feature?
We need it due to specific on-site security considerations.
There
Hi Carlo,
On Wed, Dec 23, 2015 at 12:44 AM, Carlo Milanesi
wrote:
> On 12/22/2015 09:14 PM, Piotr Grzybowski wrote:
>>
>> [..] Whats your locale?
>
>
> I originally set partially it_IT locales, and partially en_US locales, then
> changed all to en_US, but I still have
On Tue, Dec 22, 2015 at 8:07 PM, Carlo Milanesi
wrote:
> On 12/22/2015 03:38 PM, Chet Ramey wrote:
>>
>> On 12/21/15 7:38 PM, Carlo Milanesi wrote:
>>> Description:
>>> Every time I insert a character in a command-line in a position
>>> followed by some characters and some blanks, Bash c
Hey,
As an administrator, when I faced this issue I usually used some
wicked sourcing in standard bash startup files to get one global file
that gets sourced by default (last time I wanted one per group of
users, etc).
It would be useful; at least for me. How much harm can it do? If the
file is
On Mon, Dec 21, 2015 at 2:27 PM, Greg Wooledge wrote:
>
> If you are trying to advocate for a new feature in bash, it would behoove
> you to use an example that ACTUALLY DEMONSTRATES how it would be useful.
> Not a bogus example in which the feature is not only unnecessary, but
> harmful as well.
On Mon, Dec 21, 2015 at 2:21 PM, Greg Wooledge wrote:
> On Sat, Dec 19, 2015 at 12:58:41AM +0100, Piotr Grzybowski wrote:
>> #2
>> touch /tmp/`date +%s`; if [ -f /tmp/`date +%s` ]; then echo "ok: $^"; fi;
>
> This is both wrong (insecure) and clumsy. You can&
g
El 19/12/2015 03:46, "Stephane Chazelas"
escribió:
> 2015-12-19 00:58:41 +0100, Piotr Grzybowski:
> > Thanks for taking time to answer. Of course it is the issue of
> > programming style (isnt it true that most things can be brought down
> > to the programming style
El 19/12/2015 03:46, "Stephane Chazelas"
escribió:
>
> 2015-12-19 00:58:41 +0100, Piotr Grzybowski:
> > [..]
> > Without $^ it begins to look terrible.
>
> Using a variable is the most obvious thing to do.
not always practical.
>
> Also, what if "ne
On Wed, Dec 16, 2015 at 8:44 PM, konsolebox wrote:
>
> Just my quick thoughts:
>
> Pros:
> 1) It could make code smaller.
> 2) It could make writing code less prone to typos.
> 3) It could make writing code faster.
thanks. that was exactly the idea behind it.
> Cons:
> 1) The constant assignmen
Dear Stephane,
thanks.
On Wed, Dec 16, 2015 at 7:36 PM, Stephane Chazelas
wrote:
> What's wrong with
>
> f=/tmp/myfile; [ -f "$f" ] && { echo "$f is here"; head -n 1 < "$f"; }
nothing. sometimes it is just not practical (see my answer to Chet's
comment) and sometimes you just want to get that
ome ideas,
just let me think, and lets just hope I will not retreat into myself
after you say that $^ is useless ;-)
cheers,
pg
On Wed, Dec 16, 2015 at 8:12 PM, Chet Ramey wrote:
> On 12/16/15 10:03 AM, Piotr Grzybowski wrote:
>> Dear All,
>>
>> one thing I missed for some t
On Thu, Dec 17, 2015 at 2:02 AM, Chet Ramey wrote:
> On 12/14/15 2:52 AM, Piotr Grzybowski wrote:
>> Hey,
>>
>> [..] solved the issue by --without-bash-malloc which could indicate a bug or
>> lack of
>> proper support in lib/malloc/malloc.c for his platform.
Dear All,
one thing I missed for some time now, is the ability to access the
argument passed to test, or any argument on the right hand side.
I needed it so I made a quick hack, which I attach as a reference.
It allows to access arg in the the -f $arg easily, e.g.:
[ -f /tmp/myfile ] && { echo
Hi All,
for some time I had been struggling with the logging system in my
scripts. I wanted it to automatically detect the status of last
executed command, print the customizable time stamp, work from within
functions, and so on. For me it took a couple of lines of echo, output
redirection, and i
Hey,
we have had an off--list discussion with Kai on this (to shorten the
30 mails we exchanged ;-) I am writing this summary). He solved the
issue by --without-bash-malloc which could indicate a bug or lack of
proper support in lib/malloc/malloc.c for his platform. However, we
were unable to get
hi,
On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote:
> On 12 Dec 2015 15:06, Bob Proulx wrote:
>> It will almost
>> certainly get in the way of a reasonable use case.
>
> can you name a reasonable use case this breaks ?
source /media/noexecmountpoint/sh/functions.sh;
find_all_files_with_e
Hello Mike,
you want to forbid reading and interpreting scripts from the mount
point that is marked as noexec. If nothing gets executed from the
noexec area, as in your example, this is going to far.
After this, do I have to move all my scripts away from the noexec
area if I want bash to read th
hey,
this is triggered by (), since the following works as "expected":
bash -c 'foo() { readonly a=1; echo a=$a; }; foo; echo a=$a'
cheers,
pg
On Sat, Nov 28, 2015 at 4:18 AM, ziyunfei <446240...@qq.com> wrote:
> $ ksh -c 'foo() { readonly a=(1);echo a=$a; }; foo; echo a=$a'
> a=1
> a=1
> $
diff --git a/builtins/set.def b/builtins/set.def
index f582a41..c585fa5 100644
--- a/builtins/set.def
+++ b/builtins/set.def
@@ -653,6 +653,9 @@ set_builtin (list)
{
switch (flag_name)
{
+ case GETOPT_HELP:
+builtin_usage ();
+return (EX_USAGE);
case 'i':
loops forever:
set_builtin at ./set.def:654
652 while ((flag_name = internal_getopt (list, optflags)) != -1)
654 switch (flag_name)
cheers,
pg
On Tue, Oct 27, 2015 at 1:25 PM, Greg Wooledge wrote:
> On Tue, Nov 10, 2015 at 04:32:26PM +0800, ziyunfei wrote:
>>
>>
>>
>
> Noth
O WARRANTY, to the extent permitted by law.
> bash-4.3$ ls -l /bin.sh
> ls: cannot access /bin.sh: No such file or directory
> bash-4.3$ ls -l /bin/sh
> lrwxrwxrwx 1 root root 9 Oct 23 2015 /bin/sh -> /bin/bash
> bash-4.3$ ^C
>
> -Original Message-
> From: Piotr G
otr,
>
> Actually when process com is not needed, "com.sh" will not be launched
> instead of commenting one line.
> I have never tried that. From the coredump log of 4.3, seems it crashed
> before line 187. (crashed at 114).
> Thank you.
>
> -----Original
t;
> The process named "com" launched by script command "com.sh start". Pls refer
> to the attached files. It looks easy, doesn't it?
>
> @Piotr,
>
> Sure. Every equipment has the possibility of the issue.
>
>
> -Original Message-
>
hey,
just out of curiosity, does this fix it (sorry I just finished when
you wrote that it had been fixed):
diff --git a/bashhist.c b/bashhist.c
index d4c62e7..9b5cf5d 100644
--- a/bashhist.c
+++ b/bashhist.c
@@ -354,7 +354,7 @@ save_history ()
int r;
hf = get_string_value ("HISTFILE");
-
hi,
maybe I am mistaken, but I think that keeping track of the
variables/functions bound/unbound by the loadable bultins leads to a
complete hell of unmanageable code.
It should be noted, that the builtins should clean by themselves,
e.g., in this case mypid.c should contain something like:
int
case '^': case '@':
case '$': case '`': /* expansion chars */
return (1);
case '~': /* tilde expansion */
what do you think?
cheers,
pg
On Wed, Feb 4, 2015 at 3:42 PM, Greg Wooledge wrote:
On Wed, Feb 4, 2015 at 2:39 PM, Greg Wooledge wrote:
> On that note, today I learned that you are not allowed to use either *
> or @ as the index of an associative array in bash. I guess I can see why,
> but... that's probably going to break something some day.
:)
of course you can ;-)
decla
Hey,
without checking the source: reset utility from ncurses fixes your term.
this one is reproducible.
cheers,
pg
On Sun, Dec 21, 2014 at 9:28 PM, Richard W. Marsden wrote:
> steps to produce
>
> hide cursor
> setterm -cursor off
>
> call the bash built-in read command as follows: sil
On Thu, Dec 18, 2014 at 3:08 PM, Chet Ramey wrote:
>
> What the original complaint refers to is what to do in the infrequent
> case when the terminal goes away, the kernel doesn't deliver a SIGHUP,
> and a read returns EOF instead of -1.
>
I cannot reproduce it in anyway. I flooded the session l
On Wed, Dec 17, 2014 at 2:34 PM, Jiri Kukacka wrote:
>
> I investigated the bug, and I found that this happens when machine is too
> slow to send SIGHUP. This also happens when I open a terminal in GUI, and
> close the window (click X). To simulate this, one can just open XTerm
> window, ssh to an
1 - 100 of 151 matches
Mail list logo
