Feature Request re: syslog and bashhist
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 to make the change in the config file with the added benefit that it draws attention to an otherwise dormant feature. 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 Other examples from AIX syslog Aug 09 18:00:07 x053 daemon:info x053 qlogd[10148]: conn log: Users: michael, Source IP: 192.168.129.5, Computer name: study, Connection type: SAMBA, Accessed resources: michael/Pictures/desktop.ini, Action: Read Aug 9 17:00:12 x071 user:info syslog: /etc/ifconfig -a Aug 9 17:00:22 x071 auth|security:crit su: BAD SU from michael to root at /dev/pts/0 Aug 9 17:00:28 x071 auth|security:notice su: from michael to root at /dev/pts/0 Aug 09 18:16:19 x053 auth|security:info x053 qlogd[10148]: conn log: Users: guest, Source IP: 192.168.129.5, Computer name: study, Connection type: SAMBA, Accessed resources: ---, Action: Login OK Aug 9 17:18:14 x071 mail:info pop3d[9044156]: Moved 14080 bytes of new mail to /home/michael/mbox from /var/spool/mail/michael host= x005.home.local [192.168.129.5] Aug 9 17:18:14 x071 mail:info pop3d[9044156]: Auth user=michael host=x005.home.local [192.168.129.5] nmsgs=11/11 Aug 9 17:18:17 x071 mail:info pop3d[9044156]: Logout user=michael host=x005.home.local [192.168.129.5] nmsgs=0 ndele=11 Note that WHEN a pid is included it is prefixed by the commandname and enclosed between []. Sincerely, Michael
Re: Feature Request re: syslog and bashhist
On 2015-08-10 10:19 PM, 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. Basically, I had not noticed it was there. It was only because I was at a customer who said they had customized their version years ago that I started searching for information about "bash and syslog". Most of those hits were about using "fc" to add commands via the external syslogger - and these are the oldest, so the first, read top hits, that I got back. One of the replies mentioned the "top" include file. This is actually, for me, the first compelling reason to switch shells for "what is provided" to what I must be certain is added. In short, having it included in ./configure simply give it much more visibility - and perhaps adoption. 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. I try to make minimal changes. There are perhaps many other 'things' to think about here. e.g., I thought about the syslog facility and level as a configureable, but have decided against - as someone could divert the log to an unmonitored facility - defeats the purpose. However, maybe being able to specify what gets logged via a define (order of arguments, length, etc) might be "nice". But, openlog() - I'll readup, but I expect that may be what "AIX" applications are using already to get "that" layout. Many thanks for your consideration! Chet
Re: Bash 4.3.30 on AIX 6.1 filename completion
On 2015-08-03 3:40 PM, Chet Ramey wrote: On 8/2/15 8:50 PM, Steve Dahl wrote: If on AIX 6.1, I mount an NFS volume exported from CentOS 6.7, Bash (4.3.30) is unable to do tab completion within that file system. If (for example) I search for files that I know exist, such as: ls -l /path/to/files/*.h ...no answers are returned even though ls -l /path/to/files ...will show those files. In the course of trying to understand why AIX didn't like our new NFS server, I found that bash's glob.c depends on opendir(), and that in a simple test on that NFS file system, opendir() fails with EOVERFLOW. The AIX man page for opendir() documents opendir64() but doesn't go into a lot of detail about what it's for other than the inferred hint that it might allow for file sizes larger than 4 GB. The same simple test that gets EOVERFLOW when I use opendir() indeed seems to succeed when I use opendir64(). Once you know the answer, you can find hints on IBM forums that seem to confirm it. Is there already a version of "bash" somewhere that already supports large file systems on AIX if its compilation is configured right? Bash and Readline don't use opendir64/readdir64 directly. You might be able to get it to work by using cpp defines in lib/readline/complete.c Chet Actually, I am working on a "scandir" program myself, where I am using opendir(). The simpliest approach seems to be this at the start of the code, i.e., before ANY include files are inserted. One of it's effects is to make all opendir() calls automatically convert to opendir64() - no code changes needed, and the code works on both AIX - and debian (Linux on Power) that I have tested. /* * define _LARGE_FILES needs to be first so that all the include files know that */ #ifdef _AIX #define _LARGE_FILES #endif Hope this helps!
Re: Bash 4.3.30 on AIX 6.1 filename completion
On 2015-08-12 12:38 PM, aixtools wrote: On 2015-08-03 3:40 PM, Chet Ramey wrote: On 8/2/15 8:50 PM, Steve Dahl wrote: If on AIX 6.1, I mount an NFS volume exported from CentOS 6.7, Bash (4.3.30) is unable to do tab completion within that file system. If (for example) I search for files that I know exist, such as: ls -l /path/to/files/*.h ...no answers are returned even though ls -l /path/to/files ...will show those files. In the course of trying to understand why AIX didn't like our new NFS server, I found that bash's glob.c depends on opendir(), and that in a simple test on that NFS file system, opendir() fails with EOVERFLOW. The AIX man page for opendir() documents opendir64() but doesn't go into a lot of detail about what it's for other than the inferred hint that it might allow for file sizes larger than 4 GB. The same simple test that gets EOVERFLOW when I use opendir() indeed seems to succeed when I use opendir64(). Once you know the answer, you can find hints on IBM forums that seem to confirm it. Is there already a version of "bash" somewhere that already supports large file systems on AIX if its compilation is configured right? Bash and Readline don't use opendir64/readdir64 directly. You might be able to get it to work by using cpp defines in lib/readline/complete.c Chet Actually, I am working on a "scandir" program myself, where I am using opendir(). The simpliest approach seems to be this at the start of the code, i.e., before ANY include files are inserted. One of it's effects is to make all opendir() calls automatically convert to opendir64() - no code changes needed, and the code works on both AIX - and debian (Linux on Power) that I have tested. /* * define _LARGE_FILES needs to be first so that all the include files know that */ #ifdef _AIX #define _LARGE_FILES #endif Hope this helps! p.s. - rather than actually add this to ALL source files, adding -D_LARGE_FILEs to CPP_FLAGS and/or to CFLAGS is probably the better approach.
Re: Feature Request re: syslog and bashhist
On 2015-08-12 3:19 PM, Chet Ramey wrote: On 8/12/15 8:09 AM, Aharon Robbins wrote: In article, aixtools wrote: In short, having it included in ./configure simply give it much more visibility - and perhaps adoption. Personally, I think that having bash send executed commands to syslog is an invasion of privacy; I'm surprised such a feature is even there at all... And this is why it's not easy to turn on. It's there for that small set of system administrators who need it to satisfy some external auditing requirement (in some cases legally required) -- that's why it's available in the first place. I guess my customer set all fall into this category. And it is not fail safe - anyone willing, or able to use another shell can execute a program such as vi, and then use a shell escape to start a different shell that is not logging. Which is why auditing is used, which is involuntary from an application perspective. So, referring back to John's addition, this would be useful for case #2. Where it could be useful for case #3 - would be if bash had (or maybe has) an option to display the configure arguments (which generally does not include -D flags), such as perl -V, or httpd -V. Basically, if you have nothing to hide - it should not matter. More likely, it is a mechanism that can prove your innocence should there ever be any doubt about what you did, or did not do. Even in Germany - which has the reputation for most "protective" privacy laws. To meet PCI compliance and others (I think even government in some sectors) - all commands are stored in order to perform an audit in the case of a suspected security breach. In any case, I understand that it is a sensitive topic - not one that I will be deciding. I guess it might be worth a discussion to be able to see from a command-line option to know, one way or the other if the feature is (potentially) active. In short - Chet - as if I had a choice :p @ me - I bow to your wisdom!
Re: Bash-4.4-beta available for FTP
On 2015-10-15 16:23, Chet Ramey wrote: The first beta release of bash-4.4 is now available with the URL ftp://ftp.cwru.edu/pub/bash/bash-4.4-beta.tar.gz First attempt at build on AIX configure warns that bison is not available - good. configure finishes - good make fails immediately because yacc is not installed - not good make distclean; ./configure; ./make fails - need to reinstall tarball, so make distclean cleans up something ./configure does not prepare. Will continue to research and post more asap.
Re: Bash-4.4-beta available for FTP
On 2015-10-22 21:47, aixtools wrote: On 2015-10-15 16:23, Chet Ramey wrote: The first beta release of bash-4.4 is now available with the URL ftp://ftp.cwru.edu/pub/bash/bash-4.4-beta.tar.gz First attempt at build on AIX configure warns that bison is not available - good. configure finishes - good make fails immediately because yacc is not installed - not good make distclean; ./configure; ./make fails - need to reinstall tarball, so make distclean cleans up something ./configure does not prepare. Disregard this comment. I ran make with and without stdout redirection so it looked as if one was doing more than the other. Both fail at the same point. More complete report follows. Will continue to research and post more asap.
Re: Bash-4.4-beta available for FTP
reeware/lib/rpm/macros /usr/opt/freeware/share/locale/pt_BR /usr/opt/freeware/lib/rpm/check-prereqs /usr/opt/freeware/share/locale/fr/LC_MESSAGES/rpm.mo /usr/src /usr/opt/freeware/share/locale/fr/LC_MESSAGES /usr/opt/freeware/lib/librpm.so.0 -> librpm.so.0.0.0 /usr/opt/freeware/share/locale/fi/LC_MESSAGES /usr/opt/freeware/share/locale/cs/LC_MESSAGES /usr/opt/freeware/share/locale/ja/LC_MESSAGES/rpm.mo /usr/opt/freeware/bin/rpm2cpio /usr/opt/freeware/man/man8/rpm2cpio.8 /usr/opt/freeware/lib/rpm/rpmdiff.cgi /usr/opt/freeware/src/packages/SPECS /usr/opt/freeware/lib/rpm/rpmputtext /usr/opt/freeware/src/packages/RPMS/powerpc /usr/opt/freeware/share/locale/sr/LC_MESSAGES/rpm.mo /usr/opt/freeware/lib/rpm/magic.req /usr/opt/freeware/lib/rpm/brp-strip-comment-note /usr/opt/freeware/lib/rpm/rpmrc /usr/linux /usr/opt/freeware/lib/rpm/getpo.sh /usr/opt/freeware/share/locale/tr/LC_MESSAGES /usr/opt/freeware/lib/rpm/http.req /usr/opt/freeware/share/locale/ro/LC_MESSAGES /usr/opt/freeware/lib/rpm/convertrpmrc.sh /usr/opt/freeware/bin/patch /usr/opt/freeware/lib/rpm/cpanflute /usr/opt/freeware/lib/rpm/find-prov.pl /usr/opt/freeware/bin/bzcat /usr/opt/freeware/bin/bzip2 /usr/opt/freeware/share/locale/pl/LC_MESSAGES/rpm.mo /usr/opt/freeware/bin/gendiff /usr/sbin/updtvpkg /usr/bin/rpm /usr/opt/freeware/lib/librpmbuild.so.0.0.0 /usr/opt/freeware/lib/rpm/perl.prov /usr/opt/freeware/share/locale/ro/LC_MESSAGES/popt.mo /usr/opt/freeware/lib/librpmbuild.so -> librpmbuild.so.0.0.0 /usr/opt/freeware/share/locale/de/LC_MESSAGES /usr/opt/freeware/lib /usr/opt/freeware/bin/bzip2recover /usr/opt/freeware/share/locale/sk/LC_MESSAGES/popt.mo /usr/opt/freeware/lib/rpm/find-requires.perl /usr/opt/freeware/src/packages/SOURCES /usr/opt/freeware/man/man1/gendiff.1 /usr/linux/bin /usr/opt/freeware/lib/librpm.so -> librpm.so.0.0.0 /usr/opt/freeware/src/packages/BUILD /usr/opt/freeware/man/man1 /usr/opt/freeware/man/man8 Path: /etc/objrepos rpm.rte 3.0.5.41 /var/opt/freeware/lib /etc/rpm /var/lib /etc/info-dir /var/opt/freeware /var/opt/freeware/lib/rpm -> /usr/opt/freeware/packages root@x064:[/data/prj/gnu/bash/bash-4.4] At the moment I have many additional "aixtools" installed as I have been working on a different project. I will test with less later. root@x064:[/data/prj/gnu/bash/bash-4.4]lslpp -L aixtools.\* Fileset Level State Type Description (Uninstaller) aixtools.Python.man2.7.8.0C Fman pages 2014.Oct.14 07.21 CUT aixtools.Python.rte2.7.8.0C FPython 2014.Oct.14 07.21 CUT aixtools.buildaix.man.en_US 2.0.3.1C Fman pages aixtools.buildaix.rte 2.0.3.1C F1540 1007 2004 aixtools.expat.man 2.0.1.0C Fbuilt 1507 0215 1556 aixtools.expat.rte 2.0.1.0C Fexpat 1507 0215 1556 aixtools.freetype.man.en_US 2.5.5.0C Fman pages aixtools.freetype.rte 2.5.5.0C F1540 1010 1840 aixtools.freetype.share2.5.5.0C Funiversal pages aixtools.gnu.autoconf.man.en_US 2.69.0.0C Fman pages aixtools.gnu.autoconf.rte 2.69.0.0C F1530 0730 0702 aixtools.gnu.autoconf.share 2.69.0.0C Funiversal pages aixtools.gnu.automake.man.en_US 1.15.0.0C Fman pages aixtools.gnu.automake.rte
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
Sent from my iPhone > On 11 Mar 2021, at 18:15, Chet Ramey wrote: > > On 3/11/21 11:28 AM, Michael Felt wrote: >> Hi, >> Issue: AdoptOpenJDK build process makes bash calls in a particular way. An >> abbreviated (shorter pathnames) example is: >> ``` >> bash-5.0$ /usr/bin/printf "Building targets 'product-images legacy-jre-image >> test-image' in configuration 'aix-ppc64-normal-server-release'\n" > >> >(/usr/bin/tee -a /home/aixtools/build.log) 2> >(/usr/bin/tee -a >> /home/aixtools/build.log >&2) >> Building targets 'product-images legacy-jre-image test-image' in >> configuration 'aix-ppc64-normal-server-release' > > I believe this is fixed in bash-5.1. Would it be difficult to give me a hint for 5.0. I could test further now i have a command that generates the issue. > > >> I added some debug statements to try and catch what is not happening. It >> seems that the fifo_list[i].proc value is never being set to (pid_t)-1 so >> any call to `unlink_fifo()` or `unlink_fifo_list()` does not unlink the >> special file created. > > Probably because the process substitution does not exit before the shell does. I was hoping that is what the wait routines were for. Also noticed that the second fifo never gets a pid. > -- > ``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/
Re: issues in bash found while creating command result display
Sent from my iPhone > On 17 Apr 2019, at 01:37, Paul Wise wrote: > >> On Tue, 2019-04-16 at 14:57 -0400, Chet Ramey wrote: >> >> Why take so much effort to (imperfectly) figure out and display >> things you already know? > > Correctness. If what the user knows You mean think they know, better is believe. > doesn't match what the program > knows And, if not a bug, which someone who knows will “know”, better, recognize or suspect as a bug. Otherwise the program does not “know” but better (re)acts as instructed. In short, you can never, for 100%, enhance the UI to an extent a program can inform the user they’re trying to do something “unexpected” or explain why something is not the recommended approach. My 2 cents! 😃 > then they might think that the program is buggy or that there is > something malicious on their system causing errors in order to make > them doubt their own mind. > > -- > bye, > pabs > > https://bonedaddy.net/pabs3/
