Re: Feature Request re: syslog and bashhist
On 10 Aug 2015 16:19, Chet Ramey wrote: > On 8/9/15 1:37 PM, aixtools wrote: > > 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. we had requests in Gentoo, so the feature is behind a USE flag so people can easily turn it on for their systems. no need to grub around in the source and locate an obscure define. -mike signature.asc Description: Digital signature
Re: shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
chupilirola
Re: -e does not take effects in subshell
On 8/13/15, Eric Blake wrote: > Like it or not, it is the historical behavior standardized by POSIX. It > is NOT intuitive, and our advice is "DON'T USE set -e - IT WON'T DO WHAT > YOU WANT". We can't change the behavior, because it would break scripts > that rely on the POSIX-specified behavior. > POSIX didn't say anything about shopt set-e-that-actually-makes-sense. --- xoxo iza
Re: -e does not take effects in subshell
On 08/12/2015 09:54 PM, PRC wrote: > 1. If the function is complicated and contains lots of commands, it > would be more troublesome appending && to every command rather > than simply using one single "set -e" at the front. > 2. It is not > reasonable that suppression of '-e' is applied as well inside the > function. My intention is if my_build succeeds continue to do other > stuff. Does anyone like the rule that a function never fails only if it is > part of a > compound command? Like it or not, it is the historical behavior standardized by POSIX. It is NOT intuitive, and our advice is "DON'T USE set -e - IT WON'T DO WHAT YOU WANT". We can't change the behavior, because it would break scripts that rely on the POSIX-specified behavior. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: -e does not take effects in subshell
1. If the function is complicated and contains lots of commands, it
would be more troublesome appending && to every command rather
than simply using one single "set -e" at the front.
2. It is not
reasonable that suppression of '-e' is applied as well inside the
function. My intention is if my_build succeeds continue to do other
stuff. Does anyone like the rule that a function never fails only if it is part
of a
compound command?
> Date: Tue, 11 Aug 2015 09:50:56 -0400
> From: wool...@eeg.ccf.org
> To: ijk...@msn.com
> CC: bug-bash@gnu.org
> Subject: Re: -e does not take effects in subshell
>
> On Tue, Aug 11, 2015 at 11:42:29AM +, PRC wrote:
> > mybuild()
> > {
> > (
> > set -e
> > make
> > echo "build okay"
> > )
> > }
> >
> > mybuild && do_other_stuff
>
> http://mywiki.wooledge.org/BashFAQ/105
>
> Since mybuild is invoked as part of a compound command, set -e is
> suppressed. I guess this applies not only to set -e that's invoked
> beforehand, but even to set -e that's set within the compound command.
>
> Stop using set -e and all of these problems simply go away.
>
> mybuild() {
> make && echo "build okay"
> }
>
> mybuild && do_other_stuff
problems with traps
This segfaults when it receives a SIGUSR1: #!/bin/bash trap ': $(:) < <(:)' USR1 while :; do sleep 1; done I also received a bunch of scary errors like these: *** Error in `/bin/bash': munmap_chunk(): invalid pointer: 0x02680f80 *** *** Error in `/bin/bash': corrupted double-linked list: 0x01e54200 *** *** Error in `/bin/bash': free(): invalid size: 0x0115ff80 *** *** Error in `/bin/bash': double free or corruption (out): 0x00e7af60 *** https://gist.github.com/anonymous/9b24b3ca0a6ce2203fc8 and bash used 100% of a cpu, but they appeared inconsistently while trying to debug a script that trapped the SIGWINCH signal. I'll post more details if needed (and if I can reproduce them). >From gdb it looks like the problems are in jobs.c This is the backtrace for the segfault, but it doesn't explain the rest: Program received signal SIGSEGV, Segmentation fault. 0x0044d2e5 in find_pipeline (pid=19266, alive_only=1, jobp=0x7fffdff8) at jobs.c:1357 1357 if (p->pid == pid && ((alive_only == 0 && PRECYCLED(p) == 0) || PALIVE(p))) (gdb) bt #0 0x0044d2e5 in find_pipeline (pid=19266, alive_only=1, jobp=0x7fffdff8) at jobs.c:1357 #1 0x0044d419 in find_process (pid=19266, alive_only=1, jobp=0x7fffdff8) at jobs.c:1396 #2 0x00450e0a in waitchld (wpid=-1, block=0) at jobs.c:3393 #3 0x00450b7c in sigchld_handler (sig=17) at jobs.c:3280 #4 #5 0x0048e0c8 in builtin_address_internal (name=0x7645d0 ":", disabled_okay=0) at common.c:829 #6 0x0048e251 in find_shell_builtin (name=0x7645d0 ":") at common.c:866 #7 0x0043c6bf in execute_simple_command (simple_command=0x763e50, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x738220) at execute_cmd.c:4200 #8 0x004367f1 in execute_command_internal (command=0x763da0, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x738220) at execute_cmd.c:813 #9 0x00435dd3 in execute_command (command=0x763da0) at execute_cmd.c:416 #10 0x0043ae49 in execute_while_or_until (while_command=0x764130, type=0) at execute_cmd.c:3432 #11 0x0043adb4 in execute_while_command (while_command=0x764130) at execute_cmd.c:3400 #12 0x00436a55 in execute_command_internal (command=0x764240, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x764050) at execute_cmd.c:920 #13 0x00435dd3 in execute_command (command=0x764240) at execute_cmd.c:416 #14 0x00421a04 in reader_loop () at eval.c:163 #15 0x0041f856 in main (argc=2, argv=0x7fffe9b8, env=0x7fffe9d0) at shell.c:760 Hope this helps... --- xoxo iza
Re: segfault when indirectly expanding negative numbers
On 8/12/15 3:52 PM, isabella parakiss wrote:
> Bash segfaults when trying to do this: x=-3; echo ${!x}
> Here's the backtrace from gdb: https://gist.github.com/306f16a358527b267a1e
> It looks like the problem is the savestring macro when ind is negative.
Thanks for the report. This will be fixed in the next version of bash.
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/
segfault when indirectly expanding negative numbers
Bash segfaults when trying to do this: x=-3; echo ${!x}
Here's the backtrace from gdb: https://gist.github.com/306f16a358527b267a1e
It looks like the problem is the savestring macro when ind is negative.
---
xoxo iza
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: Feature Request re: syslog and bashhist
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. -- ``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/12/15 6:31 AM, aixtools wrote: > In short, having it included in ./configure simply give it much more > visibility - and perhaps adoption. Don't assume that wide adoption of this feature is a goal. -- ``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: Bash 4.3.30 on AIX 6.1 filename completion
On 8/12/15 6:38 AM, aixtools wrote: > /* > * define _LARGE_FILES needs to be first so that all the include files know > that > */ > #ifdef _AIX > #define _LARGE_FILES > #endif That define is in config.h and should be set by the AC_SYS_LARGEFILE autoconf macro. If it's not working on AIX I would send a message to bug-autoconf and ask whether that support was added in a recent version. 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: Feature Request re: syslog and bashhist
On Wed, Aug 12, 2015 at 08:00:24AM -0500, John McKown wrote: > Case 2: I'm running bash on my employer's system???. Do I really have an > expectation of privacy on my employer's system? Why would I? In some countries, yes, there is such an expectation. Logging your employees' activities may or may not be legal in any specific jurisdiction. Consult a lawyer for details.
Re: Feature Request re: syslog and bashhist
On Wed, Aug 12, 2015 at 7: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... > I can envision three scenarios. And only in one case would I consider it to be an invasion of privacy. Case 1: I'm running bash on a system which I own & control. Since I control it, I can't consider it an invasion of my privacy. Of course, I could simply recompile BASH without the option. Case 2: I'm running bash on my employer's system. Do I really have an expectation of privacy on my employer's system? Why would I? I argue this being, somewhat, in charge of some auditing on my employer's IT system. We basically log just about everything. But that is, at least supposed to be, explained as a condition of employment by HR. We are an insurance company and so have a lot of different states' regulations about data access. Case 3: I'm a paying client on some sort of "hosting" computer. Here, I might have an expectation of privacy. But I'd want to read their terms of service to be sure. If they "reserve the right to do as they please" (so to speak), then I'd try to find another company. I guess that I'm thinking of something like Amazon or Google. Even in this case, if I have a "shell" account I could most likely download BASH and compile it with my own options, excluding the syslog logging, and run it instead of the hosting company's supplied version of BASH. Which, for all I know, could be "hacked" to do know who-knows-what (putting on my paranoid security admin hat). > > My two cents, > And I respect that. > > Arnold > -- > Aharon (Arnold) Robbins arnold AT skeeve DOT com > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown
Re: Feature Request re: syslog and bashhist
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... My two cents, Arnold -- Aharon (Arnold) Robbins arnold AT skeeve DOT com
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: 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: 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
