Re: Feature Request re: syslog and bashhist
On 10.08.2015 22:19, Chet Ramey wrote:
On 8/9/15 1:37 PM, aixtools wrote:
Hi,
Via google I came across the define named
config-top.h:/* #define SYSLOG_HISTORY */
Changing it (manually) to
config-top.h:#define SYSLOG_HISTORY
Adds syslog statements such as:
Aug 9 16:52:55 x064 user:info syslog: HISTORY: PID=262242 UID=0 ls -ltr
Request #1
Add a ./configure variable, e.g., --with-syslog_history
I will think about this, but I am inclined not to do it. It's easy enough
to enable for those few user who want to do so.
Request #2
At the request of a bash user on AIX I made the following change to make
the syslog output "standardized" to AIX format for many applications so
that the output looks like this:
Aug 9 17:30:12 x064 user:info syslog: bash[454682]: UID=0: ls -ltr
The better way to do this is to use openlog(). I will add the necessary
pieces to call openlog with the shell name as the identifier and LOG_PID
as the default value for the log options.
Chet
We have recently had a customer request for this, and Steve Grubb corrected
the original patch for auditing. IIRC, aureport-2.4.2 should be able to
handle the USER_TTY
events now. With his permission, I'm attaching the new patch.
Thanks
Ondrej
diff -urp bash-4.3.orig/lib/readline/readline.c bash-4.3/lib/readline/readline.c
--- bash-4.3.orig/lib/readline/readline.c 2015-04-08 12:06:23.079210184 -0400
+++ bash-4.3/lib/readline/readline.c 2015-04-08 14:20:13.254638488 -0400
@@ -57,6 +57,7 @@ extern int errno;
#if defined (HAVE_DECL_AUDIT_USER_TTY)
# include
+# include
# include
# include
#endif
@@ -340,38 +341,31 @@ rl_set_prompt (prompt)
static void
audit_tty (char *string)
{
+ struct audit_message req;
struct sockaddr_nl addr;
- struct msghdr msg;
- struct nlmsghdr nlm;
- struct iovec iov[2];
size_t size;
int fd;
size = strlen (string) + 1;
- fd = socket (AF_NETLINK, SOCK_RAW, NETLINK_AUDIT);
+ fd = socket (PF_NETLINK, SOCK_RAW, NETLINK_AUDIT);
if (fd < 0)
return;
- nlm.nlmsg_len = NLMSG_LENGTH (size);
- nlm.nlmsg_type = AUDIT_USER_TTY;
- nlm.nlmsg_flags = NLM_F_REQUEST;
- nlm.nlmsg_seq = 0;
- nlm.nlmsg_pid = 0;
- iov[0].iov_base = &nlm;
- iov[0].iov_len = sizeof (nlm);
- iov[1].iov_base = string;
- iov[1].iov_len = size;
+ if (NLMSG_SPACE(size) > MAX_AUDIT_MESSAGE_LENGTH)
+return;
+
+ memset(&req, 0, sizeof(req));
+ req.nlh.nlmsg_len = NLMSG_SPACE(size);
+ req.nlh.nlmsg_type = AUDIT_USER_TTY;
+ req.nlh.nlmsg_flags = NLM_F_REQUEST;
+ req.nlh.nlmsg_seq = 0;
+ if (size && string)
+memcpy(NLMSG_DATA(&req.nlh), string, size);
+ memset(&addr, 0, sizeof(addr));
addr.nl_family = AF_NETLINK;
- addr.nl_pad = 0;
addr.nl_pid = 0;
addr.nl_groups = 0;
- msg.msg_name = &addr;
- msg.msg_namelen = sizeof (addr);
- msg.msg_iov = iov;
- msg.msg_iovlen = 2;
- msg.msg_control = NULL;
- msg.msg_controllen = 0;
- msg.msg_flags = 0;
- (void)sendmsg (fd, &msg, 0);
+
+ sendto(fd, &req, req.nlh.nlmsg_len, 0, (struct sockaddr*)&addr, sizeof(addr));
close (fd);
}
#endif
@@ -426,9 +420,9 @@ readline (prompt)
RL_SETSTATE (RL_STATE_CALLBACK);
#endif
-#if HAVE_DECL_AUDIT_TTY && defined (ENABLE_TTY_AUDIT_SUPPORT)
+#if HAVE_DECL_AUDIT_USER_TTY && defined (ENABLE_TTY_AUDIT_SUPPORT)
if (value)
-_rl_audit_tty (value);
+audit_tty (value);
#endif
return (value);
diff -urp bash-4.3.orig/lib/readline/util.c bash-4.3/lib/readline/util.c
--- bash-4.3.orig/lib/readline/util.c 2013-09-02 13:36:12.0 -0400
+++ bash-4.3/lib/readline/util.c 2015-04-08 14:18:21.165632509 -0400
@@ -539,53 +539,3 @@ _rl_settracefp (fp)
}
#endif
-
-#if HAVE_DECL_AUDIT_USER_TTY && defined (ENABLE_TTY_AUDIT_SUPPORT)
-#include
-#include
-#include
-
-/* Report STRING to the audit system. */
-void
-_rl_audit_tty (string)
- char *string;
-{
- struct sockaddr_nl addr;
- struct msghdr msg;
- struct nlmsghdr nlm;
- struct iovec iov[2];
- size_t size;
- int fd;
-
- fd = socket (AF_NETLINK, SOCK_RAW, NETLINK_AUDIT);
- if (fd < 0)
-return;
- size = strlen (string) + 1;
-
- nlm.nlmsg_len = NLMSG_LENGTH (size);
- nlm.nlmsg_type = AUDIT_USER_TTY;
- nlm.nlmsg_flags = NLM_F_REQUEST;
- nlm.nlmsg_seq = 0;
- nlm.nlmsg_pid = 0;
-
- iov[0].iov_base = &nlm;
- iov[0].iov_len = sizeof (nlm);
- iov[1].iov_base = string;
- iov[1].iov_len = size;
-
- addr.nl_family = AF_NETLINK;
- addr.nl_pid = 0;
- addr.nl_groups = 0;
-
- msg.msg_name = &addr;
- msg.msg_namelen = sizeof (addr);
- msg.msg_iov = iov;
- msg.msg_iovlen = 2;
- msg.msg_control = NULL;
- msg.msg_controllen = 0;
- msg.msg_flags = 0;
-
- (void)sendmsg (fd, &msg, 0);
- close (fd);
-}
-#endif
Re: \? is missing in "3.1.2.4 ANSI-C Quoting" in Bash Reference Manual
Sorry, I didn't understand your reply. What I'm saying is this: \? is shown in printf section: "Causes printf to expand backslash escape sequences in the corresponding argument, except that ‘\c’ terminates output, backslashes in ‘\'’, ‘\"’, and ‘\?’ are not removed, and octal escapes beginning with ‘\0’ may contain up to four digits.” but it isn't documented in https://www.gnu.org/software/bash/manual/html_node/ANSI_002dC-Quoting.html correspondingly after \’ and \”. Please correct me if I am missing the point. 在 2015年9月2日，下午11:32，Chet Ramey 写道： > On 9/2/15 10:00 AM, ziyunfei wrote: >> bash-4.3$ echo $'\?' >> ? >> >> \? should be added there. > > Backslash-escape sequences that are not present in the documentation are > left unchanged. Posix leaves these up to the implementation. > > -- > ``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/
Re: \c-handling in $'-strings
On 09/02/2015 03:10 PM, Helmut Karlowski wrote: >> >> The Posix standardization of $'...' requires that the character after the > > Where is that described? I could not find anything about $'...' in the > posix-docs. http://austingroupbugs.net/view.php?id=249 It's not part of POSIX yet; but the current wording in that bug report is the probable starting point for including it in the next major revision of POSIX (which will be known as Issue 8, and is several years out on the horizon). The intent of the austingroupbugs.net pages is to document what people can start implementing now, even before POSIX finally makes it official. And this very issue has just been under some recent revisions; comment 2793 mentions that some wording revisions were proposed just last month. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: \c-handling in $'-strings
Am 02.09.2015, 14:19 Uhr,SCHRIEB Chet Ramey : echo $'\c?' |od -a echo $'\c[\c\\c]\c^\c_\c?' |od -a bash prints: 000 us nl 002 000 esc fs c ] rs us us nl I'd expect: 000 del nl 002 000 esc fs gs rs us del nl Also the ] in the output seems wrong, looks it gets the \\ wrong, though ksh93 does this also. The Posix standardization of $'...' requires that the character after the Where is that described? I could not find anything about $'...' in the posix-docs. `\c' honor backslash escaping. Since the character becomes \c\\, the subsequent `c' and `]' are literals. I assume this is only true for "to-be-escaped" characters, that is $ ` " \ like for ".."-strings? Of course only \ is of interest here. If that is true then the output of ksh93 for echo $'\c\d' |od -a -> 000 eot nl is wrong? It removes the \ every time. -Helmut
Re: Why does a Bash shell script write prompts followed by reads and do it right?
On 09/02/2015 02:22 PM, Bob Proulx wrote:
> Robert Parker wrote:
>> fputs(shortprompt, stdout);
>> fflush(stdin);
>
> Uhm... fflush'ing stdin? That doesn't make sense.
There is one case where fflush(stdin) is useful on a terminal: it lets
you discard any pending input. For example, if you have just prompted
for a password and altered the tty to not echo what is typed, then
flushing stdin prior to reading the password is a nice step to ensure
that any accidental type-ahead data entered before the prompt doesn't
get mixed up with the password attempt, particularly since the lack of
echoing won't show the user that the password got munged.
Additionally, fflush(stdin) on a regular file is useful for applications
that might be used in a sequence of processes, and which have scenarios
where they only partially consuming input; POSIX requires that such
applications should reset the file pointer to the last byte actually
processed so that the next process starts processing at the next byte
rather than skipping ahead by however many bytes were cached early but
left unprocessed. Example: { sed -n 1q; cat; } < file | ... - for the
'cat' to pass the remaining lines to the rest of the pipeline, the 'sed'
must rewind back to the end of the first line even if it read more than
that.
But in most coding scenarios, flushing stdin is rather rare; it wasn't
even well-specified by POSIX until 2012.
> Obviously you
> meant to flush stdout.
And in the code snippet shown here, this observation is certainly correct.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Word-splitting with here document?
On 9/2/15 2:14 PM, Clint Hepner wrote: > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: >Unexpected word splitting in here string. According to the man page, > "Pathname expansion and word splitting are not performed." This is > essentially the same wording used to explain how `[[...]]` treats its > contents, but the here string seems to behave differently. This looks like a problem. Thanks for the report; I'll take a look. -- ``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/
Re: Why does a Bash shell script write prompts followed by reads and do it right?
Robert Parker wrote: > fputs(shortprompt, stdout); > fflush(stdin); Uhm... fflush'ing stdin? That doesn't make sense. Obviously you meant to flush stdout. fputs(shortprompt, stdout); fflush(stdout); That is likely the specific problem. Unfortunately I have no time for comments about the rest of the code. Bob
Re: Why does a Bash shell script write prompts followed by reads and do it right?
Thanks guys.
Code supplied:
static void getuserinput(char *prompt, char *reply);
static int getans(char *prompt, char *choices);
int main(int argc, char **argv)
{
char namebuf[NAME_MAX];
char typebuf[NAME_MAX];
char defltbuf[NAME_MAX];
char codebuf[NAME_MAX];
char *eols = "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n";
fputs(eols, stdout);// clear terminal window
//char ans = getans("Make a choice.\n", "123");
// Option variable name.
getuserinput("Enter variable name: ", namebuf);
// Option variable type.
getuserinput("Enter variable type: ", typebuf);
// Option default value.
getuserinput("Enter variable default value: ",
defltbuf);
// Option C code.
getuserinput("Begining with an assignment operator,"
" enter C code for this option:\n ",
codebuf);
return 0;
}
void getuserinput(char *prompt, char *reply)
{
char buf[NAME_MAX];
fputs(prompt, stdout);
char *cp = fgets(buf, NAME_MAX, stdin);
cp = strchr(buf, '\n');
if (cp) *cp = '\0';// don't need eol in the result
strcpy(reply, buf);
} // getuserinput()
int getans(char *prompt, char *choices)
{
/* Prompt the user with prompt then loop showing choices until
* the user enters something contained in choices.
* Alphabetic choices like "Yn" will be case insensitive.
*/
char testchoices[16];
char shortprompt[80];
fputs(prompt, stdout);
char c;
strcpy(testchoices, choices);
size_t i;
// to be case insensitive when choices is alpha.
for (i = 0; i < strlen(testchoices); i++) {
testchoices[i] = toupper(testchoices[i]);
}
sprintf(shortprompt, "Choose one of: \"%s\" ", choices);
while (1) {
fputs(shortprompt, stdout);
fflush(stdin);
scanf(" %c", &c);
c = toupper(c);
if (strchr(testchoices, c)) {
break;
}
}
return c;
} // getans()
In my example this line is commented out:
//char ans = getans("Make a choice.\n", "123");
On compilation in this state I get this result:
Enter variable name: avar
Enter variable type: int
Enter variable default value: 0
Begining with an assignment operator, enter C code for this option:
= 1
which is exactly what I want.
OTOH when I take the comments off that line here is what I get:
Make a choice.
Choose one of: "123" 1
*Enter variable name: Enter variable type: *
Enter variable default value: 0
Begining with an assignment operator, enter C code for this option:
= 1
So getans() is the origin of the problem.
I have spent quite some time rewriting that and in the above it is the
cleanest version I've written but it has clearly caused problems down the
track.
Thanks
On Thu, Sep 3, 2015 at 1:27 AM, Ángel González wrote:
> Robert Parker wrote:
> > Yet when I attempt the same in a C program, the system always writes
> > 2 prompts, then waits for a read.
> > Does not matter if I write(1, "..."); read(0, number, buffer); or use
> > fputs("...", stdout); fgets(.
> > The result is the same.
> > And I have tried using readline without any better result.
>
> I completely agree with Bob. It looks like your C program were doing a
> loop (which your shell script doesn't!) and there's a wrong condition
> somewhere.
> But you need to show the code that is failing (provide a minimal
> program that exhibits the failure).
>
--
The Bundys, Cliven, Ted and Al. Great guys to look up to.
Re: Why does a Bash shell script write prompts followed by reads and do it right?
Robert Parker wrote:
> Yet when I attempt the same in a C program, the system always writes
> 2 prompts, then waits for a read.
> Does not matter if I write(1, "..."); read(0, number, buffer); or use
> fputs("...", stdout); fgets(.
> The result is the same.
> And I have tried using readline without any better result.
I completely agree with Bob. It looks like your C program were doing a
loop (which your shell script doesn't!) and there's a wrong condition
somewhere.
But you need to show the code that is failing (provide a minimal
program that exhibits the failure).
Word-splitting with here document?
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin13.4.0 Compiler: clang Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='darwin13.4.0' -DCONF_MACHTYPE='x86_64-apple-darwin13.4.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/Cellar/bash/4.3.30/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I./lib/intl -I/private/tmp/bash-tugB48/bash-4.3/lib/intl -DSSH_SOURCE_BASHRC uname output: Darwin patikoija 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-apple-darwin13.4.0 Bash Version: 4.3 Patch Level: 30 Release Status: release Description: Unexpected word splitting in here string. According to the man page, "Pathname expansion and word splitting are not performed." This is essentially the same wording used to explain how `[[...]]` treats its contents, but the here string seems to behave differently. Repeat-By: $ x="foobar" $ [[ $x == "foobar" ]] # succeeds, no word splitting on value of x $ cat <<< $x # Word-splitting appears to collapse the run of whitespace foo bar $ cat <<< "$x" # Whitespace preserved, as with here doc foo bar
Re: Inconsistent arithmetic evaluation of parameters
On Wed, Sep 02, 2015 at 11:24:42AM -0400, Chet Ramey wrote: > On 9/2/15 11:19 AM, Greg Wooledge wrote: > > On Wed, Sep 02, 2015 at 10:16:14AM -0500, Dennis Williamson wrote: > >> The $ is implied. > > > > That is completely absurd. (And wrong.) > > Not exactly. When the arithmetic evaluator encounters a token that is of > the form of a shell identifier (`bar'), in a context where an operand is > needed, it treats it as a shell variable and looks up the variable's > value. In that sense, it's an expansion. > > The difference between bash and dash is what each shell does with that > value. $foo and foo are not equivalent in dash, as we've already discussed: $ dash $ foo=bar bar=5 $ echo $((foo)) dash: 4: Illegal number: bar $ echo $(($foo)) 5 They are also not equivalent in bash, if I may be permitted to change the context slightly: $ bash $ foo='$(id >&2)' $ echo $((x[foo])) bash: $(id >&2): syntax error: operand expected (error token is "$(id >&2)") $ echo $((x[$foo])) uid=563(wooledg) gid=22(pgmr) groups=1002(webauth),208(opgmr) 0 So "The $ is implied" is false, in both shells, although there are some contexts where they happen to produce the same result.
Re: \? is missing in "3.1.2.4 ANSI-C Quoting" in Bash Reference Manual
On 9/2/15 10:00 AM, ziyunfei wrote: > bash-4.3$ echo $'\?' > ? > > \? should be added there. Backslash-escape sequences that are not present in the documentation are left unchanged. Posix leaves these up to the implementation. -- ``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/
Re: Inconsistent arithmetic evaluation of parameters
On 9/2/15 11:19 AM, Greg Wooledge wrote: > On Wed, Sep 02, 2015 at 10:16:14AM -0500, Dennis Williamson wrote: >> The $ is implied. > > That is completely absurd. (And wrong.) Not exactly. When the arithmetic evaluator encounters a token that is of the form of a shell identifier (`bar'), in a context where an operand is needed, it treats it as a shell variable and looks up the variable's value. In that sense, it's an expansion. The difference between bash and dash is what each shell does with that value. -- ``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/
\? is missing in "3.1.2.4 ANSI-C Quoting" in Bash Reference Manual
bash-4.3$ echo $'\?' ? \? should be added there.
Re: Inconsistent arithmetic evaluation of parameters
On Wed, Sep 02, 2015 at 10:16:14AM -0500, Dennis Williamson wrote: > The $ is implied. That is completely absurd. (And wrong.)
Re: Inconsistent arithmetic evaluation of parameters
On Wed, Sep 2, 2015 at 2:16 AM, Andreas Schwab wrote: > Dennis Williamson writes: > > > I disagree. The _expansion_ produced "bar" > > That's not an expansion. Only $ introduces an expansion. > > Andreas. > > The $ is implied. -- Visit serverfault.com to get your system administration questions answered.
Re: Inconsistent arithmetic evaluation of parameters
On 9/1/15 5:05 PM, Dennis Williamson wrote: > It's the line above those two where I demonstrate the failure in the > indirection and equivalency. > > $ echo $((foo)) # expansion succeeds, indirection fails > dash: 4: Illegal number: bar Because `foo' is expanded, but the value is not treated as an expression. The dash arithmetic evaluator never treats values resulting from expansion as expressions, only as constants. > $ echo $(($foo)) # both expansion and indirection succeed > 5 Because the arithmetic evaluator sees $(( bar )). The word expansion that happens before arithmetic evaluation expands $foo. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 is the Posix specification for arithmetic evaluation. -- ``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/
Re: Inconsistent arithmetic evaluation of parameters
On 9/1/15 12:50 AM, Clint Hepner wrote: > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > > Parameter names are recursively evaluated in an arithmetic expression, but > this > is not done consistently. Parameter names are expanded and treated as expressions where they need to be evaluated as a number, and as identifiers when they are the subject of assignment. This is the usual way to handle context-dependent evaluation. > Repeat-By: > > foo=bar > bar=5 > echo $(( foo ))# produces 5 > echo $(( foo++ )) # produces 5 > echo $foo # produces 6, not bar > echo $bar # produces 5, not 6 Consider this equivalent expression: oldfoo=foo,foo=foo+1,oldfoo Would you claim that the foo on the lhs of the assignment statement should be expanded to `bar'? How would assignments ever be performed if it were? -- ``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/
Re: Inconsistent arithmetic evaluation of parameters
On 9/1/15 4:13 PM, Dennis Williamson wrote: > The version of dash I have handy (0.5.7) has math support which IMHO is > broken: > > $ foo=bar > $ bar=5 > $ echo $foo > bar > $ echo $((foo)) > dash: 4: Illegal number: bar > $ echo $(($foo)) > 5 > $ echo $((bar)) > 5 > $ echo $(($bar)) > 5 Dash does the minimum that Posix requires for $(( )) and no more. The stuff between $(( and )) is expanded and the result is treated as an arithmetic expression. When there is something that looks like an identifier (e.g., `foo') remaining after expansion, it's treated as a shell variable whose value is assumed to be an integer constant, not an expression. Since foo expands to `bar', and `bar' is not an integer, dash throws an error. > > Note the inconsistency in support of omitting the inner dollar sign. Also > post increment produces an error and pre increment produces no error and no > action: Posix allows implementations to omit support for prefix and postfix ++ and --. If you don't implement prefix ++ and --, they are unary plus and minus operators that happen to `stack'. -- ``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/
Re: \c-handling in $'-strings
On 9/1/15 6:46 PM, Helmut Karlowski wrote: > Do you refer to the table titled "Circumflex Control Characters in stty"? > > It states for example: > > ? Yeah, that's a problem. I've fixed that. > > Running: > > echo $'\c?' |od -a > echo $'\c[\c\\c]\c^\c_\c?' |od -a > > bash prints: > > 000 us nl > 002 > 000 esc fs c ] rs us us nl > > I'd expect: > > 000 del nl > 002 > 000 esc fs gs rs us del nl > > Also the ] in the output seems wrong, looks it gets the \\ wrong, though > ksh93 does this also. The Posix standardization of $'...' requires that the character after the `\c' honor backslash escaping. Since the character becomes \c\\, the subsequent `c' and `]' are literals. Chet -- ``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/
Re: Inconsistent arithmetic evaluation of parameters
Dennis Williamson writes: > On Tue, Sep 1, 2015 at 4:24 PM, Andreas Schwab > wrote: > >> Dennis Williamson writes: >> >> > $ echo $((foo)) # expansion succeeds, indirection fails >> > dash: 4: Illegal number: bar >> >> The indirection didn't fail, it just didn't produce a number, so the >> expression is malformed. >> >> Andreas. >> >> -- >> Andreas Schwab, sch...@linux-m68k.org >> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 >> "And now for something completely different." >> > > I disagree. The _expansion_ produced "bar" That's not an expansion. Only $ introduces an expansion. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
