On Fri, Jan 26, 2018 at 11:05:09AM -0500, Greg Wooledge wrote: > Yes, it's a bug in his script. Not in bash. > > Resource limits are quite low-level; they are implemented as kernel > system calls (see setrlimit(2)). Processes which violate a resource > limit are signalled by the kernel. > > In the case of RLIMIT_FSIZE: > > This is the maximum size of files that the process may create. > Attempts to extend a file beyond this limit result in delivery > of a SIGXFSZ signal. By default, this signal terminates a > process, but a process can catch this signal instead, in which > case the relevant system call (e.g., write(2), truncate(2)) > fails with the error EFBIG. > > If the OP wants the script to exit gracefully, then a signal trap > must be set up. Otherwise, the shell is simply terminated.
Well, actually it doesn't exit, nor terminated at all, it crash. I don't know if it is correct to define crash as an ungraceful exit. Trapping SIGXFSZ whit a break resolve the bug in my script; $ trap break SIGXFSZ; while true; do echo a>>a; done bash: echo: errore in scrittura: File troppo grande Thank you PS. this happen only when I run the script "on line", the same does it work if placed in a .sh file. -- Felipe Salvador