the inode corresponding to PATH/DIR is identical to THISINO. */
command.h and general.h are needed to avoid errors declaring other things in
externs.h -- uses of COMMAND and GENERIC_LIST.
- Jay
I don't have it handy now but I think bash also had a struct timezone
undefined, needed CFLAGS=-D_ALL_SOURCE to get it.
- Jay
From: jay.kr...@cornell.edu
To: bug-bash@gnu.org
Subject: error building bash-4.0 on Interix/SFU/SUA (MP_RMDOT undeclared, just
missing some #includes)
DNO_MAIN_ENV_ARG -DBROKEN_DIRENT_D_INO -D_POSIX_SOURCE" ;;
C:\src\bash-4.0\configure.in(1028):opennt*|interix*)
LOCAL_CFLAGS="-DNO_MAIN_ENV_ARG -DBROKEN_DIRENT_D_INO -D_POSIX_SOURCE" ;;
Is this correct?
Thanks,
- Jay
Bash on Tru64
make[1]: Entering directory '/usr/users/jay/s/bash-5.1.8/lib/sh'
cc -c -I. -I../.. -I../.. -I../../lib -I../../include -I. -I../../lib/intl
-I/usr/users/jay/s/bash-5.1.8/lib/intl -DHAVE_CONFIG_H -DSHELL -g
-Wno-parentheses -Wno-format-security input_avail.c
> Did the same thing happen when linking builtins/mkbuiltins?
Yes.
> make
rm -f mksyntax
cc -DPROGRAM='"bash"' -DCONF_HOSTTYPE='"alphaev67"' -DCONF_OSTYPE='"osf5.1b"'
-DCONF_MACHTYPE='"alphaev67-dec-osf5.1b"
> Is this gcc?
No, sorry if that wasn't clear. This is "native" cc.
> which cc
/usr/bin/cc
> cc -V
Compaq C V6.5-303 (dtk) on HP Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-302 (dtk) cc Driver
- Jay
From: Chet Ramey
Sent:
lfiles[i]->msg:((const char ...)("You
have mail in $_"))" is const, but the referenced type of the target of this
assignment is not. (notconstqual)
message = mailfiles[i]->msg ? mailfiles[i]->msg : _("You have mail in
$_");
Just adding const to these doesn't work. I could fix but I didn't.
- Jay
Oops. I was using unpatched 4.1. I missed/ignored the patches directory.
Indeed http://ftp.gnu.org/gnu/bash/bash-4.1-patches/bash41-001 is the same.
Would be nice for most/lazy folks if there was:
http://ftp.gnu.org/gnu/bash/bash-4.1p7.tar.gz
or such.
Thanks,
- Jay
On Mar 18, 6:55 pm, m...@ice.filescope.com, zy...@ice.filescope.com
wrote:
...
> When I type a long string of text and start pressing ctrl-W to
> backwards-kill words, bash deletes the words but doesn't visually refresh
> (the words still appear on the command line). This was not occurrin
e's configure.in: they break autoconf's gcc -g
detection, if nothing else.
http://svn.telesphoreo.org/trunk/data/readline/cflags.diff
Sincerely,
Jay Freeman (saurik)
sau...@saurik.com
http://www.saurik.com/
ried to do a 32-bit build of bash (using
CFLAGS='-O2 -m32 -g') and mkbuiltins.o was compiled without -m32 (as it uses
CCFLAGS_FOR_BUILD, which bypasses CFLAGS to use BASE_CCFLAGS) but was being
linked with -m32. I do not yet have a correct fix for this unrelated issue.
Sinc
that have
been functioning without issue for almost a decade.
$ bash --norc
$ function std:echo() { echo "$@"; }
$ std:echo hello world
hello world
$ export -f std:echo
$ printenv | grep std:echo -A 1
std:echo=() { echo "$@"
}
$ bash --norc
bash: error importing function definition for `std:echo'
$ std:echo hello world
bash: std:echo: command not found
Sincerely,
Jay Freeman (saurik)
sau...@saurik.com
-A 1
std:echo=() { echo "$@"
}
$ bash --norc
bash: error importing function definition for `std:echo'
$ std:echo hello world
bash: std:echo: command not found
Sincerely,
Jay Freeman (saurik)
sau...@saurik.com
- "Eduardo A. Bustamante López" wrote:
> Well, what did you expect? You're relying on undocumented features.
...
> So, fix your scripts, perhaps?
I am sorry I seem to have offended you so much to have warranted this form of
response :(.
> It's common knowledge that if you rely on undocumen
- "Ángel González" wrote:
> The patch seems straightforward:
>
> diff --git a/variables.c b/variables.c
> index 92a5a10..6552e69 100644
> --- a/variables.c
> +++ b/variables.c
> @@ -361,7 +361,7 @@ initialize_shell_variables (env, privmode)
...
> - if (legal_identifier (name))
> +
[I am terribly sorry that my In-Reply-To is wrong :/]
- "Eric Blake" wrote:
> ... Remember, the security hole of
> Shell Shock is NOT what the function is named, but the fact that
> arbitrary variable contents were being parsed. ...
Not quite: the point of exploit can be in the variable nam
> Errexit (a.k.a. set -e) is horrible,
> and you should not be using it in any new shell scripts you write.
> It exists solely for support of legacy scripts.
Wow. For those of us who don't know this, what should we be using instead? Is
using a trap on ERR any better? Is your suggestion that || ex
Hello,
I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
systems more than once either through their instability with libraries
or just excess stress.
I don't consider current case to be either of the above; see attached.
The system is modern Intel computer,
/Linux
Architecture: x86_64
SMP Enabled: Yes
Kernel Command Line:
psave=/Bionicpup64save-jay pmedia=ataflash pfix=fsck #pmedia=atahd
▶—— Distro Specifications ——◀
Distro: bionicpup64 8.0
Window Manager: JWM v2.3.7
Desktop Start: xwin jwm
Development:
Bash: 4.4.19
Geany
19 matches
Mail list logo
