Re: shouldn't prompt printing be smarter?

Paul Jarc ha scritto: Francesco Montorsi <[EMAIL PROTECTED]> wrote: why would you ever want to have the prompt printed at non-zero column of the terminal? One possible reason: so you can know whether the previous command ended its output with a newline. Otherwise the output becomes sl

Re: shouldn't prompt printing be smarter?

Hi, Bob Proulx ha scritto: PS1='${debian_chroot:+($debian_chroot)}\[\033[01;[EMAIL PROTECTED]:\[\033[01;34m\]\w\[\033[00m\]\$ ' what is it btw? That is a pretty standard Debian setting that looks to see if you are running inside of a chroot. Normally inside of a chroot on Debian systems the

Re: shouldn't prompt printing be smarter?

Hi Bob, thanks for looking into this! Bob Proulx ha scritto: Francesco Montorsi wrote: I think you all have encountered this: do a "cat somefile" where "somefile" is a text file _without_ a final newline. You'll see the prompt is printed both at the end of

shouldn't prompt printing be smarter?

Hi, I think you all have encountered this: do a "cat somefile" where "somefile" is a text file _without_ a final newline. You'll see the prompt is printed both at the end of the text printed by 'cat' and then, also at the beginning of that same line. I'm attaching a screenshot which should

Re: How to suppress async messages for background jobs

Paul Jarc ha scritto: Francesco Montorsi <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED]:~$ kwrite & =>[1] 20986 [EMAIL PROTECTED]:~$ =>[1]+ Donekwrite [EMAIL PROTECTED]:~$ is there a way to tell bash not to print those lines marked with => ? I

Re: How to suppress async messages for background jobs

Chet Ramey ha scritto: Francesco Montorsi wrote: Hi, when using & at the end of a command, bash prints messages like: [EMAIL PROTECTED]:~$ kwrite & =>[1] 20986 [EMAIL PROTECTED]:~$ =>[1]+ Donekwrite [EMAIL PROTECTED]:~$ is there a way to tell bas

How to suppress async messages for background jobs

Hi, when using & at the end of a command, bash prints messages like: [EMAIL PROTECTED]:~$ kwrite & =>[1] 20986 [EMAIL PROTECTED]:~$ =>[1]+ Donekwrite [EMAIL PROTECTED]:~$ is there a way to tell bash not to print those lines marked with => ? I could not find any comma

Re: Feature request: DOS line endings recognition

Hi, Chet Ramey wrote: Francesco Montorsi wrote: is this the right place to make feature-requests for bash ? Yes. In response to yours: I will improve the error message displayed when trying to execute a shell script with DOS line endings so the ^M doesn't cause half of the message

Re: Feature request: DOS line endings recognition

is this the right place to make feature-requests for bash ? Thanks, Francesco Montorsi ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Feature request: DOS line endings recognition

Hi, I've found out (after trying almost everything else I could coinceive), that if I make a BASH script with DOS/WIN line endings instead of UNIX line endings, when I try to run that script I get the error message: : bad interpreter: No such file or directory this is rather useless as er