they stand for.
Therefore, I propose to add the meaning of the abbreviature to the manual.
Thanks!
The referenced part:
https://www.gnu.org/software/bash/manual/bash.html#Definitions
With respect,
Alan Urmancheev
On 8/9/22 08:15, Chet Ramey wrote:
On 8/9/22 10:45 AM, Chet Ramey wrote:
On 8/8/22 5:48 PM, Alan Coopersmith wrote:
One of our users complained that bash-5.1 on Solaris 11.4, when started
with LANG=C does not allow Unicode input after changing LANG to a UTF-8
locale until bash is restarted
appen when the locale changes
after initialization - is the behavior we're seeing expected or are these
variables supposed to be automatically updated when the locale changes?
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
appen when the locale changes
after initialization - is the behavior we're seeing expected or are these
variables supposed to be automatically updated when the locale changes?
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
regards,
Alan
|
--
Dr. Alan Beccati
Jacobs University Bremen gGmbH
Department of Life Sciences and Chemistry
Guest scientist at Max Planck Institute for Marine Microbiology
Microbial Genomics and Bioinformatics Research Group
Celsiusstrasse 1
28359 Bremen
Germany
Phone: +49 (0) 421 2028 909
Thanks all, EPOCHREALTIME sounds perfect. I’m also glad to have learned
about loadable modules. Really cool.
Alan
On Thu, Nov 2, 2017 at 5:43 PM, Chet Ramey wrote:
> On 11/2/17 4:09 PM, DJ Mills wrote:
> >
> >
> > On Thu, Nov 2, 2017 at 3:35 PM, Chet Ramey > <
grateful for pointers to any existing solutions.
Thank you in advance for your thoughts, I look forward to hearing them.
Alan
Hi,
$ exec {foo}
e function
$ function f() { local x; for x; { echo "$x"; }; }
$ f a b c
a
b
c
$ typeset -p x
bash: typeset: x: not found
-Alan
On Sat, Mar 7, 2015 at 4:31 PM, Peng Yu wrote:
> Hi, I use unset to remove x from the environment once the for loop is
> finished. Is it the best
I'll agree it's non-obvious, but this works for me on a BASH 2.x I have
handy.
arwild01@BRONX:~$ echo $BASH_VERSION
2.05b.0(1)-release
arwild01@BRONX:~$ function myfunc() { :; }
arwild01@BRONX:~$ declare -f myfunc
myfunc ()
{
:
}
-Alan
On Sat, Oct 18, 2014 at 9:35 AM, Tim Fri
ut "free support" wasn't looking for Red Hat
support here. I've independently reached out to Red Hat also, but I wanted
to understand how Red Hat's patches were different from chet's patches. I
specifically wanted to Chet's solution (and directions with bash
$ bash -c 'x() { echo "functions still work" "$@"; }; export -f x;
env | egrep "functions still work"'
x=() { echo "functions still work" "$@"
but after the patch you get
-bash-3.2$ bash -c 'x() { echo "functions still work"
reasonable middle-ground then
pulling it altogether.
-Alan
On Fri, Sep 26, 2014 at 11:58 AM, Alan Wild wrote:
> I've been searching for some clarification on these two "fixes" and I'm
> utterly confused. I've been lead to believe RedHat's first patch (6271) is
&
tly. (Because I
need to know how extensively I need to reachitect my application).
-Alan
--
a...@madllama.net http://humbleville.blogspot.com
On Mon, Apr 21, 2014 at 3:16 AM, Andreas Schwab wrote:
> And if $greo is null the condition will also be true.
Really? I'll be damned. That explains this problem
I've been having.
--
Alan Young
; message:
>
> "bash: greo: command not found"
>
> /me wonders if it is mandatory first to expand the complete command line
> before realizing that the command isnÄt ther ?
>
> --
> Toralf
>
>
--
Alan Young
No, because the $greo semanti /var/db/pkg/*/*/USE line will not be
executed at all. The if [ -n $greo ] condition only passes if $greo
contains the path of the greo application.
On Sun, Apr 20, 2014 at 12:05 PM, Toralf Förster wrote:
> On 04/20/2014 07:58 PM, Alan Young wrote:
>> greo=
On Mon, Feb 11, 2013 at 02:34:53PM -0500, Greg Wooledge wrote:
> On Mon, Feb 11, 2013 at 06:59:35PM +0000, Alan Mackenzie wrote:
> > From a bash script, I'd like to be able to start several subtasks and
> > react to any one of them completing. I don't think I can do this
On Mon, Feb 11, 2013 at 03:05:25PM -0500, Chet Ramey wrote:
> On 2/11/13 1:59 PM, Alan Mackenzie wrote:
> > Hi, bug-bash.
> > From a bash script, I'd like to be able to start several subtasks and
> > react to any one of them completing. I don't think I can do this
the go at any time.
--
Alan Mackenzie (Nuremberg, Germany).
(match_list_size > 1 && _rl_complete_show_all)
display_matches (matches);*/
Then compile and install. Works great now.
On Tue, Mar 15, 2011 at 11:24 AM, Chet Ramey wrote:
> On 3/15/11 11:13 AM, Alan wrote:
>> Thanks for the response!
>>
>> The problem is
ete behave
like menu-complete did pre-readline-6.0? (In other words, behave like
'show-all-if-ambiguous' is off, while it is really on for other stuff
like tab.) Would it be best to write some sort of bash function? Or
would it be better to just modify the source code?
Thanks so much
old-menu-complete" displays ALL possible matches before cycling
through the matches on the command line.
Is there a way I can get "old-menu-complete" in bash v4 to match the
behavior of "menu-complete" in bash v3 exactly in this regard?
Thanks for your help,
Alan
es externs.h, but not includes stdio.h.
>
> ...
>
> The files which include externs.h are:
>
> bash-4.0/lib/sh/shmatch.c
> bash-4.0/make_cmd.c
> bash-4.0/input.c:#include "externs.h"
> bash-4.0/alias.c:#include "externs.h"
> bash-4.0/shell.h:#include "externs.h"
> .
>
> Of the above files 'shell.h' doesn't have 'stdio.h' included.
I had the same problem on FreeMiNT. It makes a lot of files stop
compiling just because it doesn't have the FILE * struct defined when it
hits the externs.h code.
Alan.
On Fri, 2009-05-15 at 13:19 +0200, Roman Rakus wrote:
> On 05/15/2009 12:02 PM, Alan Hourihane wrote:
> > Hi all,
> >
> > I've just compiled bash 4.0 p17 and noticed that CTRL+C isn't having any
> > effect until I hit.
> >
> > bash 3.2 worked per
Hi all,
I've just compiled bash 4.0 p17 and noticed that CTRL+C isn't having any
effect until I hit .
bash 3.2 worked perfectly, so I'm a little unsure what's caused this.
Can anyone point me at the code which handles this and I can take a
closer look ?
Thanks,
Alan.
Hi, Bob and Eric,
Thanks muchly for the help!
On Mon, Jan 28, 2008 at 04:57:22PM -0700, Bob Proulx wrote:
> Eric Blake wrote:
> > According Alan Mackenzie:
> > | % ls [A-Z]*
> > | . Sadly, ls ignores my intentions and undiscerningly prints a list of
> > | all fil
fine manual and tried:
% shopt -u nocaseglob
, but to no avail. Am I missing something obvious, or have I hit a bug?
Thanks in advance for any help!
--
Alan Mackenzie (Nuremberg, Germany).
bash's "test" builtin can report the wrong results in many
circumstances (e.g. read-only filesystems, noexec filesystems, ACLs,
NFS, AFS, setuid executables, etc) because it uses stat() rather than
access() for the unary -w, -r, -x, etc.
This has come up before:
http://lists.gnu.org/archive/html/b
Full Article:
http://service.spiegel.de/cache/international/0,1518,353274,00.html
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
30 matches
Mail list logo
