Re: Enhancement: bash should have uniform escape syntaxes for `echo -e`, `printf` and `$'ANSI_C_style_escape'`.
On 8/10/15 2:30 PM, Arthur20 wrote: > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: > Bash has different escape syntaxes for `echo -e`, `printf` and > `$'ANSI_C_style_escape'`. Take a specific point, `printf` and `$'C_Style'` > accepts octals not starting with 0, but `echo -e` doesn't. > This is causing quite a lot of confusion. They are different because they are supposed to be different according to the relevant standards. echo -e and the xpg_echo shell option expand the escape sequences that Posix specifies: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37 with the addition of \e, \E, and \xHH. Posix requires the leading 0. printf expands the escape sequences that Posix specifies: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html#tag_20_94 (note that printf %b is supposed to behave like echo) The $'...' string expansion behaves like ANSI-C, which just uses one to three octal digits for octal numbers. It adds support for \e and \E, as well as \c. There is a proposal to add this to the next version of Posix which retains this behavior. (And as for Apple's bash-3.2, they modified bash to behave as it does. Bash-3.2 as distributed understands \e in the echo format string.) -- ``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: Feature Request re: syslog and bashhist
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 -- ``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: Worth mentioning in documentation
Greg Wooledge wrote: > Juanma wrote: > > > [ is an ordinary command (a "shell builtin") > > > > Here is another point I find confusing: I thought a "shell builtin" didn't > > have a separate binary executable file, like 'cd' (which cd => fail), but > > some of them do have such form (which [ => /usr/bin/[ ; which pwd => > > /bin/pwd). I also fail to see how 'test' modifies the state of the shell > > itself (like 'cd' does), or why it is "impossible or inconvenient to obtain > > [its functionality] with separate utilities". > > Don't use which(1). Which is an external program, so it has no knowledge > of the shell's builtins, aliases, functions and keywords. Instead, use > type. Another problem with 'which' is that it was originally designed and written for csh users specifically. It was a csh script and would source the users ~/.cshrc file so as to acquire their aliases from there so as to be able to report user aliases. I think it is still that way on HP-UX (and probably others) for example. However that obviously won't work well for bash, ksh, zsh, and other shell users. And IMNHO csh is a terrible shell regardless of the tcsh users using it who think otherwise. Therefore some distributions such as Debian have rewritten 'which' as a /bin/sh script meaning that 'which' behaves differently on different systems. It is non-portable. > imadev:~$ type cd > cd is a shell builtin > imadev:~$ type [[ > [[ is a shell keyword > imadev:~$ type -a test > test is a shell builtin > test is /usr/bin/test > test is /bin/test > > Bash implements test as a builtin not because it's necessary, but simply > for efficiency. Forking a whole process to test whether two strings are > equal would be horribly wasteful. An important mental concept is that test and [ must *behave* the same as if they were an external program. They are internal builtins for efficiency now but everything behaves the same if they are external programs. This is why quoting as if they were external programs is required. On the other hand [[ has always been a builtin and therefore the shell can avoid one layer of quoting and does. Bob
Re: Enhancement: bash should have uniform escape syntaxes for `echo -e`, `printf` and `$'ANSI_C_style_escape'`.
On 08/10/2015 12:30 PM, Arthur20 wrote: > Configuration Information: > Machine Type: i686-pc-cygwin, i686-pc-msys, x86_86-linux-gnu, > x86_64-Apple-Darwin > > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: > Bash has different escape syntaxes for `echo -e`, 'echo -e' is inherently non-portable, and exists solely for backwards compatibility. As such, it is unlikely to be changed. POSIX strongly recommends that you use 'printf' instead. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Enhancement: bash should have uniform escape syntaxes for `echo -e`, `printf` and `$'ANSI_C_style_escape'`.
Configuration Information: Machine Type: i686-pc-cygwin, i686-pc-msys, x86_86-linux-gnu, x86_64-Apple-Darwin Bash Version: 4.3 Patch Level: 30 Release Status: release Description: Bash has different escape syntaxes for `echo -e`, `printf` and `$'ANSI_C_style_escape'`. Take a specific point, `printf` and `$'C_Style'` accepts octals not starting with 0, but `echo -e` doesn't. This is causing quite a lot of confusion. On older versions of bash, like bash 3.2 on OS X, `echo` doesn't understand `\e` but `printf` and `$'C_style'` does. I believe this is quite a aged problem. Repeat-By: printf 'printf starts the bold\33[1m\n'; echo $'C escape should end it\33[0m'; echo -e 'echo -e does nothing but giving crap\33[1;31m'
Re:Re: [DOC] Documentation for `complete' compacts[] is incomplete.
At 2015-08-11 01:29:42, "Chet Ramey" wrote: >Have you considered reading the man page or perhaps the info doc? That's >where the actions are documented: > > -A action > The action may be one of the following to generate a > list of possible completions: > alias Alias names. May also be specified as -a. > arrayvar > Array variable names. > >...and so on. Oops, I missed it.<>
Re: [DOC] Documentation for `complete' compacts[] is incomplete.
On 8/10/15 12:02 PM, Arthur20 wrote: > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: > Bash has incomplete documentation for builtins in `complete.def`. The > [-abcdefgjksuv] options to specify > types to complete are not documented. This is making writing > completions some kind of black magic. Have you considered reading the man page or perhaps the info doc? That's where the actions are documented: -A action The action may be one of the following to generate a list of possible completions: alias Alias names. May also be specified as -a. arrayvar Array variable names. ...and so on. -- ``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: Feature Request re: syslog and bashhist
You can add `-DSYSLOG_HISTORY` to your CFLAGS for building.
And for formatting, apply this patch:
--- bashhist.c 2015-08-11 00:09:38.449468800 +0800
+++ bashhist.c 2015-08-11 00:09:42.970623400 +0800
@@ -713,12 +713,12 @@
char trunc[SYSLOG_MAXLEN];
if (strlen(line) < SYSLOG_MAXLEN)
-syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d %s",
getpid(), current_user.uid, line);
+syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "bash[%d]: UID=%d %s", getpid(),
current_user.uid, line);
else
{
strncpy (trunc, line, SYSLOG_MAXLEN);
trunc[SYSLOG_MAXLEN - 1] = '\0';
- syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "HISTORY (TRUNCATED): PID=%d
UID=%d %s", getpid(), current_user.uid, trunc);
+ syslog (SYSLOG_FACILITY|SYSLOG_LEVEL, "bash[%d] (TRUNCATED): UID=%d %s",
getpid(), current_user.uid, trunc);
}
}
#endif
I'm not quite familiar with those configure.ac magic, and therefore I can't
write some AC_ARG_ENABLE for you.
[DOC] Documentation for `complete' compacts[] is incomplete.
Configuration Information: Machine: i686 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I. -I./include -I./lib -O1 uname output: CYGWIN_NT-10.0-WOW VAIO-lynn 2.0.4(0.287/5/3) 2015-06-09 12:20 i686 Cygwin Machine Type: i686-pc-cygwin Bash Version: 4.3 Patch Level: 30 Release Status: release Description: Bash has incomplete documentation for builtins in `complete.def`. The [-abcdefgjksuv] options to specify types to complete are not documented. This is making writing completions some kind of black magic. All those correspondence can be found in complete.def. More specifically, compacts[]. /* By the way is anyone going to assign those '\0's so we can do even more things? */ Repeat-By: help compgen, help complete, info bash, man bash. Fix: Write approporiate doc for this. I only need a transcription of compacts[] so I can look it up without Luking it.
Re: Worth mentioning in documentation
On 08/10/2015 02:18 AM, Juanma wrote: > Here is another point I find confusing: I thought a "shell builtin" didn't > have a separate binary executable file, like 'cd' (which cd => fail), Actually, POSIX requires that there be a separate 'cd' binary, although it does not have to behave the same as the shell builtin. (About all an exec'able cd can do is tell you by exit status whether the builtin cd would succeed or fail; or be used for its CDPATH side-effect of printing a directory name). GNU/Linux systems tend to ignore the POSIX requirement of exec'able counterparts, although here is how Solaris effectively does it: $ cat /bin/cd #!/bin/sh exec $(basename $0) "$@" $ and hard-linking that 2-liner to all of the shell builtins where POSIX requires to have a non-builtin counterpart. See also http://austingroupbugs.net/view.php?id=705 It is only the special builtins (such as 'exit') where POSIX does not require an exec'able counterpart. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Worth mentioning in documentation
On Mon, Aug 10, 2015 at 10:18:52AM +0200, Juanma wrote: > > [ is an ordinary command (a "shell builtin") > > Here is another point I find confusing: I thought a "shell builtin" didn't > have a separate binary executable file, like 'cd' (which cd => fail), but > some of them do have such form (which [ => /usr/bin/[ ; which pwd => > /bin/pwd). I also fail to see how 'test' modifies the state of the shell > itself (like 'cd' does), or why it is "impossible or inconvenient to obtain > [its functionality] with separate utilities". Don't use which(1). Which is an external program, so it has no knowledge of the shell's builtins, aliases, functions and keywords. Instead, use type. imadev:~$ type cd cd is a shell builtin imadev:~$ type [[ [[ is a shell keyword imadev:~$ type -a test test is a shell builtin test is /usr/bin/test test is /bin/test Bash implements test as a builtin not because it's necessary, but simply for efficiency. Forking a whole process to test whether two strings are equal would be horribly wasteful.
Re: Worth mentioning in documentation
El Fri 7 of Aug, Greg Wooledge profirió estas palabras: > > Those brackets I cited above: ( expression ) > In the US we call those "parentheses", and we reserve the word "brackets" > (or "square brackets") for [ ]. I realize that the UK uses different > terminology. Hence, the word is ambiguous and you should always type > the actual characters you mean. Lesson learned. I didn't mean to enforce UK wording; I just forgot there was a more "natural" word for me (as Eduardo noted). [...] > [ is an ordinary command (a "shell builtin") Here is another point I find confusing: I thought a "shell builtin" didn't have a separate binary executable file, like 'cd' (which cd => fail), but some of them do have such form (which [ => /usr/bin/[ ; which pwd => /bin/pwd). I also fail to see how 'test' modifies the state of the shell itself (like 'cd' does), or why it is "impossible or inconvenient to obtain [its functionality] with separate utilities". But that's another story. > You were reading the section on [[ and assuming that it applies to [. > That's a huge mistake. [...] > Do not use -a or -o. They might as well not EXIST. Just forget them. > You can't use them in [ and you can't use them in test and you can't > use them in [[. > > Use one of the syntaxes I've shown here. Huge thanks. It was a good explanation. -- Juanma Menéndez
