Re: 4.3-030 - fails to build on older HP-UX
On Sun, Oct 26, 2014 at 09:10:32AM +0100, H.Merijn Brand wrote: > 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some > very small edits) but fails HP-UX 11.11, 11.00 and 10.20 Just for the record, I have never had any trouble building Bash on HP-UX 10.20 using gcc 3.3. I suspect the number of people testing Bash with the pay-extra-money-for cc on obsolete versions of HP-UX is pretty small.
Re: 4.3-030 - fails to build on older HP-UX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/26/14, 4:10 AM, H.Merijn Brand wrote: > 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some > very small edits) but fails HP-UX 11.11, 11.00 and 10.20 Are you using gcc to build bash? I don't really go out of my way to cater to non-gcc compilers on platforms to which I don't have access. - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAlROODcACgkQu1hp8GTqdKsp8wCfdpv+fhb0YC7KiyaJOEU9tyWh l/QAnRtNnbLriDdpvZWmlzN173wMVI4Y =AtXi -END PGP SIGNATURE-
Re: 4.3-030 - fails to build on older HP-UX
On Mon, 27 Oct 2014 08:02:32 -0400, Greg Wooledge wrote: > On Sun, Oct 26, 2014 at 09:10:32AM +0100, H.Merijn Brand wrote: > > 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some > > very small edits) but fails HP-UX 11.11, 11.00 and 10.20 > > Just for the record, I have never had any trouble building Bash > on HP-UX 10.20 using gcc 3.3. I suspect the number of people > testing Bash with the pay-extra-money-for cc on obsolete versions > of HP-UX is pretty small. I will also try with gcc-3.4.6 This was just to feedback my findings Somehow it seems that I am the only one left in the world that actually makes OpenSource builds available for HP-UX older than 11.23 and looking at the number of downloads of whatever I put there, those ancient versions are still in use. http://tux.nl/itrc/web/index.html -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgp01nD0oc1MG.pgp Description: OpenPGP digital signature
Re: 4.3-030 - fails to build on older HP-UX
H.Merijn Brand wrote: 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some very small edits) but fails HP-UX 11.11, 11.00 and 10.20 The first reason is the use of C++ style comments in the source. The fix is easy. Just use plain ANSI comments. Old(er) ANSI C-compilers do NOT recognize // as command (an IMHO they should not) The POSIX standard after 2002 is no longer guaranteed to be compatible with the original POSIX standard. POSIX went from descriptive to prescriptive after 2002 and no longer limits itself to what was out there and compatible with the original POSIX specification, but has gone into incompatible specifications for 2007, 2010 et al. I.e. the new POSIX doesn't adhere to the original POSIX mission statement and is arguably not POSIX, but the new group bought the name and has no responsibility to compatibility with the original group's mission statement or specification. Sorta like "AT&T" being bought by PacBell (SBC at the time). They are different companies with completely different quality metrics and mission statements. However, many or most GNU based projects, wanting industry validation, have used compliance with the new POSIX[sic] spec as a "promotion point". Thus, for example, since strtoll was added for ISO C 2001 compatibility, any SW that isn't up to the level of 2001 standards (like ANSI C98 and prior) isn't compatible to the latest rev of the POSIX standard. The fact that post 2002 versions of POSIX aren't compatible with the original mission statement of the original standard is not relevant. The three files that ought to be fixed are lib/readline/colors.h lib/readline/colors.h lib/readline/parse-colors.c --- Maybe a sed script could filter these? Either that or if you want to use the latest software (bash 4.3) on these system, then they need to have the latest tool chains? The next issue is harder to fix. These three OS's do not seem to have easy detectable wide-char support. === Not sure how easy this would be to hack, but the last issue is fairly trivial. The last issue is building 64bit version on 11.11: ld: Unsatisfied symbol "__strtoull" in file ./builtins/libbuiltins.a[printf.o] ld: Unsatisfied symbol "__strtoll" in file general.o as on 64bit build strtoull does not exist, as strtoul already *is* strtoull (likewise for strtoll vs strtol) --- Right, so, adding a local lib that has an strtoull call that simply calls the local strtoul call would seem to be a lowest touch solution. However, the question remains, why would you want or require a newest-tool-version like bash 4.3 on an old system that doesn't support the newest-tool-version "tool chain"? Systems of 15-20 years ago that want to build current tools need to be willing to update their build-chain tools to the level required by 'current tools' -- or go suffer an increasing work load of backporting current tools (often at the expense of new development). Cheers! -L
Re: 4.3-030 - fails to build on older HP-UX
On Mon, 27 Oct 2014 07:42:39 -0700, Linda Walsh wrote: > H.Merijn Brand wrote: > > 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some > > very small edits) but fails HP-UX 11.11, 11.00 and 10.20 > > > > The first reason is the use of C++ style comments in the source. > > The fix is easy. Just use plain ANSI comments. Old(er) ANSI C-compilers > > do NOT recognize // as command (an IMHO they should not) > > The POSIX standard after 2002 is no longer guaranteed to be compatible > with the original POSIX standard. POSIX went from descriptive to prescriptive > after 2002 and no longer limits itself to what was out there and compatible > with the original POSIX specification, but has gone into incompatible > specifications for 2007, 2010 et al. I.e. the new POSIX doesn't adhere > to the original POSIX mission statement and is arguably not POSIX, but the > new group bought the name and has no responsibility to compatibility > with the original group's mission statement or specification. Yeah, standards++ > Sorta like "AT&T" being bought by PacBell (SBC at the time). > They are different companies with completely different quality > metrics and mission statements. However, many or most > GNU based projects, wanting industry validation, have used > compliance with the new POSIX[sic] spec as a "promotion point". > > Thus, for example, since strtoll was added for ISO C 2001 compatibility, > any SW that isn't up to the level of 2001 standards (like > ANSI C98 and prior) isn't compatible to the latest rev of > the POSIX standard. The fact that post 2002 versions of POSIX > aren't compatible with the original mission statement of the original > standard is not relevant. > > > The three files that ought to be fixed are > > > > lib/readline/colors.h > > lib/readline/colors.h > > lib/readline/parse-colors.c > --- > Maybe a sed script could filter these? Either that or if you want to > use the latest software (bash 4.3) on these system, then they need > to have the latest tool chains? OTOH How difficult is it to stick to consistent use of /* ... */ ? hand edited those three and that "resolves" the issue, but the issue is so unnecessary > > The next issue is harder to fix. These three OS's do not seem to have > > easy detectable wide-char support. > === > Not sure how easy this would be to hack, but the last issue is fairly > trivial. > > > The last issue is building 64bit version on 11.11: > > > > ld: Unsatisfied symbol "__strtoull" in file > > ./builtins/libbuiltins.a[printf.o] > > ld: Unsatisfied symbol "__strtoll" in file general.o > > > > as on 64bit build strtoull does not exist, as strtoul already *is* > > strtoull (likewise for strtoll vs strtol) > --- > Right, so, adding a local lib that has an strtoull call > that simply calls the local strtoul call would seem to be a lowest > touch solution. > > However, the question remains, why would you want or require > a newest-tool-version like bash 4.3 on an old system that doesn't support > the newest-tool-version "tool chain"? Yes, I do There are several reasons • I have these systems open for OpenSource developers and putting them in a 1972 version of the Bourne shell will make them scream. Besides the fact that the old bourne- or posix-shells miss a lot of features that modern developers love to see, putting them in something better that I already have ported (like tcsh) is probably not making their lives any better • Security issues. I had an old version (ranging from 3.0 to 3.2.48) version of bash already installed. Those are outdated and many fixes have been made since both security-wise and feature-wise. I find it my task to have something reasonable recent available • Some tools require bash (for testing), like git. You won't be able to pass the git test suite without bash. Let's not make their lives harder by not having it around. (You don't want to port GNU projects using HP's make either!) > Systems of 15-20 years ago that want to build current > tools need to be willing to update their build-chain tools to the > level required by 'current tools' -- or go suffer an increasing work > load of backporting current tools (often at the expense of new > development). Agree, but why make it harder from both sides? > Cheers! > -L -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgpWxw5L4t58j.pgp Description: OpenPGP digital signature
Re: 4.3-030 - fails to build on older HP-UX
On Mon, 27 Oct 2014 08:02:32 -0400, Greg Wooledge wrote: > On Sun, Oct 26, 2014 at 09:10:32AM +0100, H.Merijn Brand wrote: > > 4.3-030 builds and runs fine under HP-UX 11.31 and 11.23 (after some > > very small edits) but fails HP-UX 11.11, 11.00 and 10.20 > > Just for the record, I have never had any trouble building Bash > on HP-UX 10.20 using gcc 3.3. I suspect the number of people > testing Bash with the pay-extra-money-for cc on obsolete versions > of HP-UX is pretty small. All depots now on-line: 1540758 Oct 27 13:58 http://tux.nl/itrc/web/bash-4.3.30-10.20.sd.bz 2945990 Oct 27 14:34 http://tux.nl/itrc/web/bash-4.3.30-11.00.sd.bz 1723967 Oct 27 16:13 http://tux.nl/itrc/web/bash-4.3.30-11.11.sd.bz 1694434 Oct 24 18:24 http://tux.nl/itrc/web/bash-4.3.30-11.23-pa2.sd.bz 3458084 Oct 24 18:22 http://tux.nl/itrc/web/bash-4.3.30-11.23.sd.bz 3458460 Oct 24 18:21 http://tux.nl/itrc/web/bash-4.3.30-11.31.sd.bz When the mirrors have synced, also as http://mirrors.develooper.com/hpux/bash-4.3.30-10.20.sd http://mirrors.develooper.com/hpux/bash-4.3.30-11.00.sd http://mirrors.develooper.com/hpux/bash-4.3.30-11.11.sd http://mirrors.develooper.com/hpux/bash-4.3.30-11.23-pa2.sd http://mirrors.develooper.com/hpux/bash-4.3.30-11.23.sd http://mirrors.develooper.com/hpux/bash-4.3.30-11.31.sd -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgpsdFB86uCaa.pgp Description: OpenPGP digital signature
[PATCH] bracketed paste support
This patch adds support for "bracketed paste mode" to readline. In
this mode, readline instructs the terminal to wrap pasted strings in
special control sequences so that programs can distinguish them from
typed input. This patch makes readline insert each pasted string as
one big literal into the edit buffer; as there is no termcap
capability for bracketed paste support, the patch detects capable
terminals automatically by looking for support for similar escape
sequences.
diff --git a/lib/readline/bind.c b/lib/readline/bind.c
index 8acf4ac..7173552 100644
--- a/lib/readline/bind.c
+++ b/lib/readline/bind.c
@@ -1486,6 +1486,7 @@ static const struct {
{ "convert-meta",&_rl_convert_meta_chars_to_ascii, 0 },
{ "disable-completion", &rl_inhibit_completion, 0 },
{ "echo-control-characters", &_rl_echo_control_chars,0 },
+ { "enable-bracketed-paste", &_rl_enable_bracketed_paste,0 },
{ "enable-keypad", &_rl_enable_keypad, 0 },
{ "enable-meta-key", &_rl_enable_meta, 0 },
{ "expand-tilde",&rl_complete_with_tilde_expansion, 0 },
diff --git a/lib/readline/doc/readline.3 b/lib/readline/doc/readline.3
index ca0a81a..808b4b7 100644
--- a/lib/readline/doc/readline.3
+++ b/lib/readline/doc/readline.3
@@ -578,6 +578,13 @@ following the cursor are not duplicated.
If set to \fBOn\fP, a character denoting a file's type as reported
by \fIstat\fP(2) is appended to the filename when listing possible
completions.
+.TP
+.B enable\-bracketed\-paste (On)
+If set to \fBOn\fP and the terminal supports bracketed
+paste mode, configure it to insert each paste into the
+editing buffer as a string instead of treating
+the characters pasted as normal input, preventing inadvertent
+execution of pasted commands.
.PD
.SS Conditional Constructs
.PP
diff --git a/lib/readline/doc/rluser.texi b/lib/readline/doc/rluser.texi
index 577..0a26444 100644
--- a/lib/readline/doc/rluser.texi
+++ b/lib/readline/doc/rluser.texi
@@ -703,6 +703,13 @@ If set to @samp{on}, a character denoting a file's type
is appended to the filename when listing possible
completions. The default is @samp{off}.
+@item enable-bracketed-paste
+@vindex enable-bracketed-paste
+If set to @samp{on} and the terminal supports bracketed paste mode,
+configure it to insert each paste into the editing buffer as a string
+instead of treating the characters pasted as normal input, preventing
+inadvertent execution of pasted commands. The default is @samp{on}.
+
@end table
@item Key Bindings
diff --git a/lib/readline/funmap.c b/lib/readline/funmap.c
index 363507b..29f089b 100644
--- a/lib/readline/funmap.c
+++ b/lib/readline/funmap.c
@@ -101,6 +101,7 @@ static const FUNMAP default_funmap[] = {
{ "history-substring-search-backward", rl_history_substr_search_backward },
{ "history-substring-search-forward", rl_history_substr_search_forward },
{ "insert-comment", rl_insert_comment },
+ { "bracketed-paste-begin", rl_bracketed_paste_begin },
{ "insert-completions", rl_insert_completions },
{ "kill-whole-line", rl_kill_full_line },
{ "kill-line", rl_kill_line },
diff --git a/lib/readline/kill.c b/lib/readline/kill.c
index 3d23745..79de79f 100644
--- a/lib/readline/kill.c
+++ b/lib/readline/kill.c
@@ -656,6 +656,61 @@ rl_yank_last_arg (count, key)
return retval;
}
+/* We've recognized a terminal control sequence telling us to expected
+ * pasted content. Read characters from the terminal until we read a
+ * bracketed paste end sequence, treating the characters read as
+ * literal text to insert. */
+int
+rl_bracketed_paste_begin (count, key)
+ int count, key;
+{
+ static const char endseq[] = "\033[201~";
+ static const int endseqlen = sizeof (endseq) - 1;
+
+ int rv = -1;
+ int c;
+ size_t len = 0;
+ size_t cap = 16;
+ char *buf = xmalloc (cap);
+
+ RL_SETSTATE(RL_STATE_MOREINPUT);
+ while (0 <= (c = rl_read_key ()))
+{
+ if (RL_ISSTATE (RL_STATE_MACRODEF))
+_rl_add_macro_char (c);
+
+ if (c == '\r')
+c = '\n';
+
+ if (len == cap)
+buf = xrealloc (buf, (cap *= 2));
+
+ buf[len++] = c;
+ if (len >= endseqlen &&
+ !strncmp (&buf[len - endseqlen],
+endseq,
+endseqlen))
+{
+ len -= endseqlen;
+ break;
+}
+}
+ RL_UNSETSTATE(RL_STATE_MOREINPUT);
+
+ if (c >= 0)
+{
+ if (len == cap)
+buf = xrealloc (buf, (cap += 1));
+
+ buf[len++] = '\0';
+ rl_insert_text (buf);
+ rv = 0;
+}
+
+ xfree (buf);
+ return rv;
+}
+
/* A special paste command for users of Cygnus's cygwin32. */
#if defined (__CYGWIN__)
#include
diff --git a/lib/readline/readline.c b/lib/readline/readline.c
index f8211e7..d6e9775 100644
--- a/lib/readline/readline.c
+++ b/lib/readline/readline.c
@@ -302,6 +302,11 @@ int _rl_revert_all_at_newline = 0;
characters corresponding to keyboard-g
