Emanuele Torre wrote:
> Also here is a paste with some examples by rwp:
> https://paste.debian.net/plain/1206849
That paste is going to exire so here is the contents of it.
I wanted to show exactly what characters were in the file being edited
and therefore set VISUAL to od in order to du
Chet Ramey wrote:
> Tomas Janousek wrote:
> > Chet Ramey wrote:
> >> Yes, you can disable bracketed paste mode. I'll make sure that turning off
> >> bracketed paste mode disables the active region for incremental searches.
> >
> > Would you please consider making this configurable separately? I'd
Chet Ramey wrote:
> This release fixes several outstanding bugs in bash-5.0 and introduces
> several new features.
An unlisted change (I couldn't locate it in the changes) is that
'reverse-search-history (C-r)' now highlights the search pattern. Is
that because it is the search pattern or because
Robert Elz wrote:
> ps: I did not suggest that $_ should go away, I know that's not going to
> happen ... just that it would be nice for those who really don't want it to
> be able to turn it off.
I'm having a hard time understanding why one would want to turn off
this feature. It isn't somethin
Dirk Wetter wrote:
> PS + @Bob: fd 5 is not a tty in the program -- but interactively in
> this PoC you want to make sure it is not taken yet.
Understood. I originally mentioned the isatty() thing because that is
how libc decides to line buffer or not. But Chet has confirmed that
bash's internal
Chet Ramey wrote:
> b...@feusi.co wrote:
> > The thing I noticed is that when setting a variable and then running the
> > command "time", bash reports "command not found". For example, the
> > command:
> >
> > TEST=1 time ls
> >
> > Results in "bash: time: command not found"
That would work if y
Mike Gerwitz wrote:
> Bob Proulx wrote:
> > Let me give the discussion this way and I think you will be
> > convinced. :-)
>
> Well, thanks for taking the time for such a long reply. :)
>
> > How is your example any different from a C program? Or Perl, Python,
&
Chet Ramey wrote:
> Bob Proulx wrote:
> > Put this in your ~/.bashrc file and I believe your use case will be
> > much happier.
> >
> > shopt -s checkhash
>
> How many installers put a new version of an existing package into a
> possibly-different directory
Hi Mike,
Mike Gerwitz wrote:
> ... but are you saying that terminating with a segfault is the
> intended behavior for runaway recursion?
Let me give the discussion this way and I think you will be
convinced. :-)
How is your example any different from a C program? Or Perl, Python,
Ruby, and so f
Jeffrey Walton wrote:
> I think a useful feature for Bash would be to automatically update the
> program cache after an install.
Put this in your ~/.bashrc file and I believe your use case will be
much happier.
shopt -s checkhash
In the bash manual:
checkhash
Chet Ramey wrote:
> It's that bash sets stdout and stderr to be line-buffered, not anything
> printf-specific.
Shouldn't bash set stdout buffering based upon the output descriptor
being a tty or not the same as other libc stdio behavior?
Bob
Chet Ramey wrote:
> Bob Proulx wrote:
> > It was also noted in another message that the external standalone
> > printf command line utility did buffer as you desired. That seems
> > another very good solution too. Simply use "command printf ..." to
> > force
Robert Elz wrote:
> Bob Proulx wrote:
> | Using the same buffer size
> | for input and output is usually most efficient.
>
> Yes, but as the objective seemed to be to make big packets, that is probably
> not as important.
The original complaint concerned flushing a data
Robert Elz wrote:
> ps: f there was actually a desire to use dd to do re-buffering, the
> correct usage is not to use "bs=" (which simply does read write with
> a buffer that size) but "obs=" which reads (using ibs if needed, which it
> would not be here), copies to an output buffer and writes only
I see that you have subscribed now. Awesome! If you and others would
be so kind as to list-reply instead of CC'ing me directly that would
be great. I read the replies on the mailing list.
dirk+b...@testssl.sh wrote:
> Bob Proulx wrote:
> > You are doing something that is quite
dirk+b...@testssl.sh wrote:
> we discovered a strange phenomenon in the project testssl.sh:
You are doing something that is quite unusual. You are using a shell
script direction on a TCP socket. That isn't very common. More
typically one would use a C program instead. So it isn't surprising
th
Greg Wooledge wrote:
> L A Walsh wrote:
> > I remember some implementations only wait till the clock reaches the
> > new time in seconds -- meaning that the actual sleep time could be
> > .001 seconds.
>
> If true, that would actually violate POSIX. The sleep time must be
> "at least" as long as
Bize Ma wrote:
> > but just the same it is almost always possible
> > to refactor a program into a different algorithm that avoids the need
> > to enumerate so many arguments in memory.
>
> As you say: "almost".
I still believe that to be true. Since you haven't shared what the
actual task is th
I followed along through the script:
> m=2
...
> test1() { ...
Eventually I got to this line:
> set -- $(seq $m)
At that line I see that bash must allocate enough memory to hold all
of the numbers from 1 through 2 in memory all at one time. That
is very inefficient. That
Chet Ramey wrote:
> Hi. I am considering making bash glob expansion implement rational range
> interpretation starting with bash-5.0 -- basically making globasciiranges
> the default. It looks like glibc is going to do this for version 2.28 (at
> least for a-z, A-Z, and 0-9), and other GNU utilitie
Chet Ramey wrote:
> Bob Proulx wrote:
> > Denys Vlasenko wrote:
> >> $ f() { for i; do echo "|$i|"; done; }
> >> $ x=x
> >> $ e=
> >> $ f ${x:+ ""}
> >> ^^^ prints nothing, bug?
> >>
> >> $ $
Denys Vlasenko wrote:
> $ f() { for i; do echo "|$i|"; done; }
> $ x=x
> $ e=
> $ f ${x:+ ""}
> ^^^ prints nothing, bug?
>
> $ ${x:+"" }
> ^^^ prints nothing, bug?
Insufficient quoting. That argument should be quoted to avoid the
whitespace getting stripped. (Is that during wor
Chet Ramey wrote:
> On 6/23/18 3:44 PM, L A Walsh wrote:
> > Seems like the original missed being sent toe the bug-bash alias.
>
> It was not posted to bug-bash.
For bug-bash was in the hold queue for human moderation. Although it
seems off topic for this mailing list it has already had three re
Garreau, Alexandre wrote:
> Subject: Editing previous lines while in here-document mode (< Not only because this is often frustrating and impractical, but also
> because this tends to cause inconsistency feeling, I think it would be
> ...
This is just my opinion but one that follows from the timel
Danyel Bayraktar wrote:
> Bash should idle in (e.g.) /tmp or /var/folders/xyz, i.e. occupy
> that file as ‘CWD’ towards the OS, but obviously not expose this to
> depending code, so still spawn every child process/builtin/keyword
> inside the (memory-stored) cwd which will be updated with `cd` and
Eduardo A. Bustamante López wrote:
> Alfred Baroti wrote:
> > Hi,
> > I found this from long long time ago.
> > Is this a serious bug?
> [...]
>
> This is not a serious bug at all. It's just a memory allocation failure.
Agreed. Not a bug at all.
> You can see that the brk() system call actually
Kevin Layer wrote:
> It took me hours of work to distill this down from a very large and long
> running script.
> set -eu
Hours and hours of debug time could be saved if people stopped using
'set -e' in their programs. It creates more problems than people
think it solves. Do not meddle in the a
Eric Engstrom wrote:
> doh - thanks - didn't think of that, and that makes more sense.
>
> Nevermind then.
In the /usr/share/doc/bash/README.Debian.gz file:
5. What is /etc/bash.bashrc? It doesn't seem to be documented.
The Debian version of bash is compiled with a special option
(-DSYS_B
Yuri wrote:
> Bob Proulx wrote:
> > How is the user logging in? Are they logging in with 'ssh' over the
> > network? Or are they logging in through an "xdm" X Display Manager
> > login from a graphical login display?
>
> User logs in locally throug
Yuri wrote:
> None of these files are executed when bash is a user's default shell on
> FreeBSD.
> No special options were selected. Despite shell.c saying that they should be
> executed they just aren't.
How is the user logging in? Are they logging in with 'ssh' over the
network? Or are they lo
same with this being my
last comment here upon it too.
> Bob Proulx said (in a message with the original subject):
> | You can use the shared kitchen but please leave it in a better state than
> | you found it.
>
> That would be fine, and would be free use. But
>
>
Robert Elz wrote:
> Bob Proulx wrote:
> > However this difference in philosophy does not change the technology
> > that creating a compiler for an interpreted language is very hard.
> > Maybe impossible.
>
> No. Not impossible, not even all that difficult, just i
Saint Michael wrote:
> I use Linux. My business to provide services for problems that I solve, as
> you mention, by calling Awk, sed, join, etc., and databases.
Sounds good. I classify myself the same way. :-)
> I allow my customers to login to a box that I provide in my
> datacenter. I cannot a
Jonny Grant wrote:
> Please keep my email address in any replies
>
> Bob Proulx wrote:
> > Jonny Grant wrote:
> > > Yes, it's a known limitation of POSIX that it uses a shared error code for
> > > both files and directors, ENOENT. Which without programmer
Saint Michael wrote:
> Dear Maintainer
Note that I am not the maintainer.
> Is there a commercial or free software that can take a Bash script and
> transparently turn it into a C executable, provided the machines where it
> runs has any of the external commands like awk, etc?
Not as far as I am
Jonny Grant wrote:
> Greg Wooledge wrote:
> > The wording is taken directly from perror() and related library calls,
> > as translated for your locale.
>
> Yes, it's a known limitation of POSIX that it uses a shared error code for
> both files and directors, ENOENT. Which without programmers handl
Kevin Brodsky wrote:
> The thing is, "the next level of the program" really is another program,
> i.e. the one that invoked it, and you are communicating via the exit
> status, so it's certainly not as explicit as re-throwing an exception in
> C++, for instance. But sure, once you are aware of this
Kevin Brodsky wrote:
> To be fair, killing oneself when receiving SIGINT is quite
> counter-intuitive, POSIX is not helping here.
Really? It seems intuitive to me that at any trap handling level one
should handle what needs to be handled and then raise the signal
higher to the next level of the p
Kevin Brodsky wrote:
> $ bash -c '(trap "echo INT; exit 1" INT; sleep 60s); echo after'
> ^CINT
> after
> $
This is a good example of a bad example case. You shouldn't "exit 1"
or you will replace the information that the process is exiting due to
a signal with an error code. The trap handler sh
Kae Verens wrote:
> but, if you do this:
> cd // ; pwd
>
> then the CLI reports
> //
Using two "//" at the start of a path name is special because in some
systems it means the path component that follows is a hostname.
Therefore it must be preserved verbatim.
Bob
Phi Debian wrote:
> I tried to subscribe to bug-bash but never got the confirmation mail.
You must have successfully received and replied to the confirmation
email because I looked at the subscriber list and you are subscribed.
Obviously not needed now but if you have trouble with the mailing
list
Chet Ramey wrote:
> On 1/24/17 2:07 AM, Brian 'geeknik' Carpenter wrote:
> > Going through some ancient bug reports and I came across
> > https://savannah.gnu.org/support/index.php?108884 which apparently nobody
> > uses anymore.
> >
> > <<$(()())|>_[$($(<<0)) crashes bash on Debian, Red Hat, Free
Peng Yu wrote:
> My point is why bash terminates when it runs an external command that
> requires a large memory. Shouldn't bash return an exit code on behalf
> of the failed command and continue to the next command?
Note that I am going to say something without looking at the source
code of bash
XiaoBing Jiang wrote:
> Greg Wooledge wrote:
> > If you want to ENSURE that the child shell process is replaced by the
> > external sleep 20, use an explicit exec.
>
> yes, I want to know why bash not optimize this. or any strategy ?
Because it wouldn't save anything significant. Since the parent
Richard Lohman wrote:
> Problem is, I'd like the output to resemble other syslog messages:
> Mmm dd HH:MM:SS hostname bash[pid]: command
> And ultimately drop the username in as well. Since only bash is logging in
I suggest using the 'logger' command instead of modifying bash.
Normally I am doi
psko...@gmail.com wrote:
> [a-z]) echo "Character is in Lowercase";;
> [A-Z]) echo "Character is in Uppercase";;
What is the output of 'locale' for you? It will almost certainly show
that your LC_COLLATE is *NOT* set to the C locale but to some other
locale. Your statemen
Reuti wrote:
> While we are on this: wondering about the difference about -h and -L I found
> that `man test` outputs on OS X:
>
> " -h file True if file exists and is a symbolic link. This
> operator is retained for compatibility with pre-
>vious versions of this
Eduardo A. Bustamante López wrote:
> When I try to clone:
> | dualbus@hp ~ % git clone git://git.savannah.gnu.org/bash.git
> | Cloning into 'bash'...
> | fatal: Could not read from remote repository.
Connection was closed immediately.
> | Please make sure you have the correct access rights
>
Anis ELLEUCH wrote:
> I would like to ask if it is possible to disable expanding asterisk when it
> selects all entries ?
You ask if it is possible and the answer is no it is not possible.
Because the shell expands the "*" before it passes the result as
arguments to the rm command. The rm command
Cuong Manh Le wrote:
> I'm sorry for that. It's not the time between post but after sending the
> email, I look at the help-bash archive and see it have no active email
> since January.
There has been lots and lots of email in the archive since January.
http://lists.gnu.org/archive/html/help-ba
Greg Wooledge wrote:
> On Wed, Feb 24, 2016 at 11:31:40AM +0700, Cuong Manh Le wrote:
> > I send this email to help-bash but it seems to be inactive. Please help me
> > with this problem. Thanks.
>
> help-bash is active. You probably just didn't wait long enough.
> If this is your first message t
Benno Schulenberg wrote:
> Bob Proulx wrote:
> > I do not have a nanorc file at all. The defaults are okay for
> > suspension without any specific configuration.
>
> ?? How does that work? What version of nano are you using?
Since this has nothing to do bash I am goin
Benno Schulenberg wrote:
> Bob Proulx wrote:
> > [...] this is the perfect case for job control. No need for a
> > second terminal. Here is an example. Use Control-Z to stop the
> > foreground job.
>
> For that to work, it requires having 'set suspend' i
Nick Warne wrote:
> I was in a SSH session, and checking something inadvertently issued:
>
> > nano /var/log/messages | grep a
>
> (I was searching for something else than an 'a', but the above example shows
> the issue - about to use 'nano', but then forgot to change it to 'cat').
>
> The termi
Val Krem wrote:
> Dave Rutherford wrote:
> > date -d 'next month' +%b%Y
> >
> > Note, I'm not sure that's robust if you call it on, say, the 31st of the
> > month
> > if the next month doesn't have 31 days. It might give you two months from
> > now.
> > Read the man page for date for further enl
Mike Frysinger wrote:
> But bash itself has no problem running this file:
> $ bash /dev/shm/test.sh
> hi
>...
> This detracts from the security of the overall system. People
> writing scripts sometimes want to save/restore state (like
> variables) and will restore the content from a noexec poi
Linda Walsh wrote:
> Bob Proulx wrote:
> >Where does the OS claim it is a file descriptor?
> 1) in the kernel documentation:
> file 'devices.txt:
> /dev/fd /proc/self/fd symbolicFile descriptors
That shows the file descriptor map for the process.
Linda Walsh wrote:
> Greg Wooledge wrote:
> >A simple example:
> >diff -u <(sort file1) <(sort file2)
> You claim <(sort file1) is a filename?
Me too.
> >touch a
> >mv <(sort a) <(sort a)
> mv: cannot move ‘/dev/fd/63’ to ‘/dev/fd/62’: Operation not permitted
>
> The OS claims that <() gen
Eduardo A. Bustamante López wrote:
> $ some long command I've typed
> And then boss calls: URGENT! Run uptime and tell me the output, I'll:
> $ some long command I've typed
> Press Ctrl-u
> $ _
> Write uptime RET
> $ uptime
> 11:23:45 up 4 days, 22:39, 4 users, load average: 0.51, 0.86, 0.75
>
Linda Walsh wrote:
> Haven't used ksh for some timeI thought the '!' stuff came
> from csh? It seemed so pointless, since having to look up
> things by command number I thought, was way too much work... searching
> via a string in the line seemed so much faster...
You are not thinking about t
Greg Wooledge wrote:
> Just for the record, ping is the *classic* example of an incorrectly
> written application that traps SIGINT but doesn't kill itself with
> SIGINT afterward. (This seems to be true on multiple systems -- at
> the very least, HP-UX and Linux pings both suffer from it.)
The c
Greg Wooledge wrote:
> Brian Carpenter wrote:
> > While fuzzing GNU bash version 4.3.42(1)-release
> > (x86_64-unknown-linux-gnu) with AFL(http://lcamtuf.coredump.cx/afl), I
> > stumbled upon a 4-byte 'script' that triggers a null ptr deref and causes a
> > segfault.
> >
> > https://savannah.gnu.o
Robert Parker wrote:
> fputs(shortprompt, stdout);
> fflush(stdin);
Uhm... fflush'ing stdin? That doesn't make sense. Obviously you
meant to flush stdout.
fputs(shortprompt, stdout);
fflush(stdout);
That is likely the specific problem. Unfortunately I have no
John McKown wrote:
> Not a bug, so likely the wrong forum.
Agreed.
> Have you tried doing a fflush() after the fputs()? I.e. something to tell
> the Kernel to "write this out immediately!".
Almost. It is the C library libc that buffers output with fputs() not
the kernel. The libc normally chec
Robert Parker wrote:
> Yet when I attempt the same in a C program, the system always writes 2
> prompts, then waits for a read.
This isn't a C list. But if you don't show us the code then no one
can give good help.
If you write, read, write and then it *must* try the read before the
second write
Andreas Schwab wrote:
> Ángel González writes:
> > entering «/^ *read⤶» may be easier to type (and remember)
>
> It won't match, though.
It matches fine for me. Although I suggest adding the square bracket
so as to avoid the other false positives as long as one knows that
read has options docum
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 [ => /u
Valentin Schmidt wrote:
> Subject: bash displays strange characters after base64 decoding
> Bash displays strange characters (including command prompt) (see attached
> png file) after the execution of the base64 (GNU coreutils 8.21) command
> like described as follows:
> base64 -d base64.txt
This
Please pardon the incorrectly handled anti-spam message re-send seen
today. One of the listhelper volunteers had a problem vivifying an
incorrectly classified false-positive-as-spam message. Accidents
happen. Your patience and tolerance is appreciated.
Bob
S. Irelan wrote:
> I have vested so very many hours and attempts and well, can't get
> out from under what I understand is the Shellshock /bash hacking
> browser attacking NIGHTMARE !!!
Your report does not indicate any similarities to the well known
"Shellshock" bug.
https://en.wikipedia.org/w
Hrazel wrote:
> It would be so cool just to [shift] + [arrow up] to go to the line of
> interest. [arrow right] to copy it to the clipboard and return to the
> normal console again. then I can decide what to do with it next.
This would need some type of wrapper around everything such as GNU
'sc
Jon Seymour wrote:
> I was surprised that this didn't work with the OSX version of bash 3.2:
>
> /bin/bash -c 'echo $(case "yes" in yes) echo yes; ;; no) echo no; ;;
> esac)'
>
> /bin/bash: -c: line 0: syntax error near unexpected token `;;'
> /bin/bash: -c: line 0: `echo $(case "yes" in ye
Ed Avis wrote:
> Thanks. So 'whoami | >out' working is a natural consequence of the
> fact that '>out' is a command by itself.
It is a natural consequence of parsing redirections before parsing
commands. The redirection happens before the command execution and an
empty command is valid. That re
Vladimir Kanazir wrote:
> Bob Proulx wrote:
> >The bash default is not to set that variable. But it looks like you
> >are using Ubuntu and the Ubuntu package default is to set it in the
> >default .bashrc file as a user level customization.
>
> Yes, they broke many t
Vladimir Kanazir wrote:
> uname output: Linux canny 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13
> 15:45:27 $
> When you type space before the command, the command is not
> saved in the history.
> You can't see it when arrow up / CTRL+P is pressed. It is
> like the command
Cheng Rk wrote:
> According this documentation `help test`, I am expecting it should
> return false on anything other than a regular file,
>
> -f FILETrue if file exists and is a regular file.
>
> but why it returned true on a symlink to a regular file?
>
> $ [ -f tmp/sym-link ] && echo
Vincent Leduc wrote:
> The null redirect was used for the /etc/issue to not be shown
> here. I mean although we dont have any tty attached, i assume the
> builtin should not do this. I only tested it with an older release,
> as you said, it seems to be corrected.
If I don't include -t then I get t
Vincent Leduc wrote:
> sh-3.2# ssh localhost bash -i 2>/dev/null
> root@localhost's password:
> [tab][tab][enter]
> Display all 1797 possibilities? (y or n)[enter]
Although I can reproduce this in bash 4.2 it is not reproducible for
me in bash 4.3. I assume that it was improved there.
One proble
Dennis Williamson wrote:
> Bob Proulx wrote:
> > I see a lot of hits in the bash_completion add-on files. Should we be
> > looking at:
> >
> > $ grep -r "shopt -s extglob" /etc/bash*
> > /etc/bash_completion.d/nmh:shopt -s extglob
> >
Greg Wooledge wrote:
> David J. Haines wrote:
> > When started interactively, bash sets the extglob shopt; however, that
> > fact seems to have been overlooked in the manpage.
>
> This is a compile-time setting. Your vendor probably turned this on.
>
> imadev:~$ bash-4.3
> imadev:~$ shopt | grep
Askar Safin wrote:
> Okey, so, Chet, what will you say about resizing bug? Is this a bug?
> At this moment I doesn't ask where (readline or konsole) this bug
> resides. I'm just asking: is this a bug? Or "long line doesn't move
> on resize" is intended behavior?
In my opinion the bug is in your ex
Artem Yegorov wrote:
> Hi, why does not the sort processes by priority? This is a bug or not?
> I attached a screenshot with a problem.
> I use VMware Workstation and Ubuntu 14.04 LTS
You seem to have confused the 'ps' command with 'bash' and reported
something that you think should be different a
Daniel Colascione wrote:
> Bob Proulx wrote:
> > I use paste into the shell with an embedded newline in order to
> > immediately execute a command *a lot*. If that were removed I would
> > be very unhappy.
>
> I strongly doubt that your use case is typical.
It does
Chet Ramey wrote:
> * paste into the text editor invoked by the `edit-and-execute-command' key
> binding (C-xC-e in emacs mode), edit the command if desired, and have the
> shell automatically execute the contents of the editing buffer when the
> editor exits
Cool! This was an idea that I h
Daniel Colascione wrote:
> Well, I don't know whether Chet left the feature enabled by
> default. I hope he did, though, since preventing execution of pasted
> commands is one of the feature's key benefits. In bash, you should
> be able to execute a pasted command sequence by typing RET after the
>
Darshit Shah wrote:
> I'm running Bash 4.3.30(1)-release on Arch Linux. Recently after I rebooted
> by system I realized that all my Bash History had been erased. The
> ~/.bash_history file existed, but it was completely empty.
>
> The situation occurred just now once again. I boot up my system an
Alexandre Ferrieux wrote:
> Greg Wooledge wrote:
> > Unfortunately, most people don't actually express an intent when they
> > use #!/bin/sh. They just copy some code from a random script they found
> > somewhere, without understanding what it means.
>
> That song reminds me of PHP. I was under t
Chet Ramey wrote:
> Bob Proulx wrote:
> > That is one of the reasons I don't like the /dev/std{err,in,out}
> > things. They are not portable. They do different things on different
> > systems. I avoid them.
>
> I've considered emulating it everywhere, rega
Greg Wooledge wrote:
> It's important to note that the following two cases are *not*
> equivalent:
>
>cat "$i" >/dev/stdout
>program -i "$i" -o /dev/stdout
>
> In the first case, the /dev/stdout is part of a redirection. On
> platforms that do not have a native /dev/stdout in the file sy
Ralf Goertz wrote:
> Actually things are more complicated. I do need the /dev/stdout part. I
> obiously don't have the problem with `cat' but with some other program
> that doesn't write to stdout per se and expects a -o parameter for the
> output file. And this program just accepts one input file.
Dennis Williamson wrote:
> Bob Proulx wrote:
> > And the subshell isn't needed either. Use a list.
> >
> > { for i in file[12] ; do cat "$i" ; done ;} > both
>
> There's no need for the curly braces and the last semicolon.
Of course you are t
Ralf Goertz wrote:
Since you have used an invalid address I assume you are reading the
mailing list via a web archive or other means and did not CC you.
> Why do I need cat (the second on) here?
You don't.
> $ echo first >file1
> $ echo second >file2
> $ (for i in file[12] ; do cat "$i" > /dev
bogun.dmit...@gmail.com wrote:
> Eric Blake wrote:
> > bogun.dmit...@gmail.com wrote:
> > > IMHO any user action should not lead to SIGSEGV! I am not objecting
> > > against
> > > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no
> > > idea why this is happened. I have made
Andreas Schwab wrote:
> Bob Proulx writes:
>
> > #!/bin/bash
> expect -c '...' "$_usr" "$_host" "$_passwd"
Of course that works too. Why were you so late to share this wisdom?
> RTFM?
It has probably been more than fifteen years s
Esben Stien wrote:
> If I run this, it works:
>
> #!/usr/bin/expect
Sounds good. Is there anything particular bad about running it as an
expect script? (Or in native python using pexepect? Or in native perl
using Perl's expect library? Or Ruby's?)
> Andreas Schwab writes:
> > Since you are
Esben Stien wrote:
> export _csv=`python <<'END'
As you have already discovered this is the source of your problem.
> /usr/bin/expect<<'EOF'
Times two, nested.
The bash documentation says:
Here Documents
This type of redirection instructs the shell to read input from
the curre
Andreas Schwab wrote:
> Chet Ramey writes:
> > Andreas Schwab wrote:
> >> AIUI there is no readline command the moves
> >> vertically within the commandline (in readline a line always includes
> >> any embedded newlines).
> >
> > That's true. How should such a command work? Move point forward and
Dani Moncayo wrote:
> Emacs uses M-p/M-n to browse the minibuffer history (and C-p/C-n to
> move to the previous/next line in a multi-line buffer), whereas Bash
> uses C-n/C-p for browsing the command history (and doesn't use M-p/M-n
> for anything, AFAIK).
>
> It would be nice to remove this inco
One of the recent postings mentioned that http://www.gnu.org/software/bash/
directed questions to bug-bash. We never updated the web page to
mention the new help-bash mailing list! I updated the web page to say
to send questions for help with bash to the help-bash list and bugs or
development iss
Mathieu Malaterre wrote:
> I am getting a weird behavior in bash. Would it be possible for the
> next release of bash to not get a SIGSEV ?
> for i in {0..4294967295}; do
> echo $i
> done
That is one of those expressions that I see and my eyes go *WIDE* with
shock! The {X..Y} expression is gene
1 - 100 of 502 matches
Mail list logo
