On 3/26/23 7:53 PM, Paul Eggert wrote:
On 2023-03-24 12:04, Chet Ramey wrote:
However, Bash's devel branch still has old-style function definitions
and therefore won't compile with a strict C23 compiler. For example,
get_variable_value in variables.c is old-style. I assume there would be
inter
On Mon, Mar 27, 2023 at 04:43:09PM -0700, L A Walsh wrote:
> On 2023/03/27 13:28, Greg Wooledge wrote:
> > You're calling filter_ssh with no arguments, but trying to use "$@"
> > inside it to generate the ssh command.
> Isn't "$@" still valid? Originally I didn't have func-filterssh, it was
> inli
On 2023/03/27 13:05, L A Walsh wrote:
That "$@" is not going to work the way you want it to in the general
case.
---
While I got rid of $@ in some test versions, it was back in
in later version, so that may be the main flaw at this point.
Will need time to clean this mess up...
On 2023/03/27 13:28, Greg Wooledge wrote:
On Mon, Mar 27, 2023 at 01:05:33PM -0700, L A Walsh wrote:
filter_ssh() {
ign0='ssh: connect to host \w+ port 22: Connection refused'
ign1='(agent returned different signature type ssh-rsa)'
ign2='(ssh_exchange_identification: read: Connectio
On Mon, 27 Mar 2023 at 18:35, Paul Eggert wrote:
> The problem can also occur on platforms where calling conventions differ
> depending on type even if the two types have the same representation, and
> this can (and has) occurred on platforms with linear address spaces.
>
Indeed, this is *normal
On Mon, Mar 27, 2023 at 01:05:33PM -0700, L A Walsh wrote:
> filter_ssh() {
>ign0='ssh: connect to host \w+ port 22: Connection refused'
>ign1='(agent returned different signature type ssh-rsa)'
>ign2='(ssh_exchange_identification: read: Connection reset by peer)'
>ign3='(packet_wri
On 2023/03/26 10:40, L A Walsh wrote:
This is mostly a test to see if this makes it through to the list.
Something else I tried to
post recently never showed up, and ...
... (sigh)
All showed up at once, once the config was fixed...*sigh*
On 2023/03/27 12:39, Greg Wooledge wrote:
You aren't showing the actual commands that the script is running, so
we have no way to verify that whatever the script is doing is identical
to what you were doing interactively.
Also:
readarray output< <(ssh -n -T "$user@$host" "$@" 2>&1)
On Mon, Mar 27, 2023 at 12:24:35PM -0700, L A Walsh wrote:
> interactive:
>
> readarray out< <(ssh -n -T "$user@$host" 'printf "1\n2\n3\n4\n5\n"' 2>&1);
> printf "%s" "${out[@]}"
> In script:
>
> on_host athenae 'printf "1\n2\n3\n4\n5\n"' Using host athenae
> 103: host athenae, up
> Read 1 lines
Don't know that this is a bug -- there is likely some reason why there's
a difference in interactive vs. script execution. Certainly is annoying!
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but for me ssh generates
1 warning mess
Don't know that this is a bug -- there maybe some reason why there's
a difference in interactive vs. script execution...certainly isn't helpful
in trying to develop a script though.
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but
Don't know that this is a bug -- there is likely some reason why there's
a difference in interactive vs. script execution. Certainly is annoying!
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but for me ssh generates
1 warning mess
Don't know that this is a bug -- there is likely some reason why there's
a difference in interactive vs. script execution. Certainly is annoying!
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but for me ssh generates
1 warning mess
Don't know that this is a bug -- there maybe some reason why there's
a difference in interactive vs. script execution...certainly isn't helpful
in trying to develop a script though.
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but
This is mostly a test to see if this makes it through to the list.
Something else I tried to
post recently never showed up, and I didn't get back an error message.
Also didn't show in
bash list archives.
Subject line of missing email:
Why difference between interactive+script doing same thin
On 3/27/23 12:49 PM, Grisha Levit wrote:
another size_t issue
Thanks for the reports.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
another size_t issue
diff --git a/bashline.c b/bashline.c
index 0047caef..9df26d2e 100644
--- a/bashline.c
+++ b/bashline.c
@@ -919,7 +919,7 @@ hostnames_matching (const char *text)
continue;
/* OK, it matches. Add it to the list. */
- if (nmatch >= (rsize - 1))
+ if ((n
On 3/26/23 7:41 PM, Paul Eggert wrote:
* lib/sh/random.c (genseed): Use a different type, to pacify GCC
"warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]" on platforms with 64-bit pointers
Thanks for the report.
--
``The lyf so short, the craft so long to lerne.'
On 3/26/23 8:52 PM, Emanuele Torre wrote:
---
parse.y | 1 +
1 file changed, 1 insertion(+)
diff --git a/parse.y b/parse.y
index 639912b6..65c1d88a 100644
--- a/parse.y
+++ b/parse.y
@@ -73,6 +73,7 @@
# include "jobs.h"
#else
extern int cleanup_dead_jobs (void);
+extern int count_all_j
On 2023-03-26 21:17, Martin D Kealey wrote:
While C has never guaranteed that pointers all have the same size &
alignment, POSIX does provide this guarantee, although indirectly (it has
to be true for dlsym() to work, for example).
My commit message was a bit misleading, as the problem is not l
20 matches
Mail list logo
