On Fri 28 Mar 2014 10:23:17 Chris Down wrote:
there's really nothing to add to Chris's wonderful post :)
-mike
signature.asc
Description: This is a digitally signed message part.
Chet Ramey wrote:
On 3/27/14, 8:42 PM, Linda Walsh wrote:
I certainly wouldn't be against a builtin that would return
the same thing as /dev/fd/62 -- just one that doesn't try to
walk an external path to perform internal functions (have looked
several times at scripts that have shown such mes
billyco...@gmail.com writes:
> > huge wall of text
First of all, please follow basic etiquette and trim your quotes to what
is relevant. I can't even fit your e-mail on my entire screen.
> On one hand I realize you think you're being helpful to someone who
> has just started bash programming, but
On 3/27/14, 8:42 PM, Linda Walsh wrote:
> I certainly wouldn't be against a builtin that would return
> the same thing as /dev/fd/62 -- just one that doesn't try to
> walk an external path to perform internal functions (have looked
> several times at scripts that have shown such messages, and
> ha
When a system is not fully up or limping, various
services like udevd may not be mounted yet -- proc may not be
mounted yet. But it appears there are features in bash that
try to use external paths to access process descriptors in
itself (rather than just using them directly).
If there is a need
On 3/27/14, 7:11 PM, Uwe Storbeck wrote:
> On Mar 27, Chet Ramey wrote:
>> Since that line, as you entered it above, is a syntax error, it's not
>> clear what bash should do with it (probably nothing). What do you
>> expect to happen?
>
> The same as if you would try to complete any non-existing
On Mar 27, Chet Ramey wrote:
> Since that line, as you entered it above, is a syntax error, it's not
> clear what bash should do with it (probably nothing). What do you
> expect to happen?
The same as if you would try to complete any non-existing file
name, nothing? The completion should not appe
On Mar 20, Chet Ramey wrote:
> I've updated the patch, and attached it. This seems to fix all of the
> reported problems from Debian's version of bash-completion.
It looks like this patch is included in Debian bash version
4.3-4. Most of my examples for bash completion which started to
fail with
On 3/27/14, 4:57 PM, Uwe Storbeck wrote:
> $ ls a(
>
> results in a wrong completion:
>
> $ ls a(a
This is something different. I addressed it in my first reply in this
thread:
"For instance, I believe that the problem with these unquoted special
characters is that they break words for re
On Thu, Mar 27, 2014 at 5:05 PM, Mike Frysinger wrote:
> thanks, i wasn't aware of that func. that seems like the easiest solution.
mapfile it awesome, but for getting find(1) results into an array you
should continue to use a read -rd '' loop. read -d is somewhat
portable, and mapfile does not
On Thu 27 Mar 2014 19:15:13 Pierre Gaston wrote:
> On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger wrote:
> > On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> > > files=()
> > > while IFS= read -r -d '' file; do
> > >
> > > files+=("$file")
> > >
> > > done < <(find . -iname '*.mp3' ! -iname
I don't believe any shell can currently read nul-delimited input into
an array without looping. It's been suggested to add a delimiter to
mapfile. It looks like mapfile uses zgetline() to wrap around calls to
zread() and doesn't support any delimiter. read(1) on the other hand
uses one of the zread
On Thu, Mar 27, 2014 at 07:36:56PM +0100, Matthias Klose wrote:
> seen when entering q!, then leaving the shell with ^D
>
> $ gdb bash
> (gdb) run
> Starting program: /bin/bash
> doko@gb:~$ q!
> q!: Befehl nicht gefunden.
> doko@gb:~$
> malloc: .././parse.y:2314: assertion botched
> realloc: start
On 3/27/14 2:36 PM, Matthias Klose wrote:
> seen when entering q!, then leaving the shell with ^D
Thanks. It's actually running any other command after the failed expansion
causes the input line to be resized. Here's a patch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
seen when entering q!, then leaving the shell with ^D
$ gdb bash
(gdb) run
Starting program: /bin/bash
doko@gb:~$ q!
q!: Befehl nicht gefunden.
doko@gb:~$
malloc: .././parse.y:2314: assertion botched
realloc: start and end chunk sizes differ
last command: q!
Aborting...
Program received signal SI
On Thursday, March 27, 2014 2:15:22 PM UTC-4, Eduardo A. Bustamante López wrote:
> > Your response is "I recommend you to use 'set -x'"? Nice. Unfortunately
> > it also means you're a troll, so further discussion with you is pointless.
>
> >
>
>
>
> Well, care to explain why I'm labeled a
Awesome, thanks for the super fast fix :)
e.
On Thu, Mar 27, 2014 at 7:26 PM, Chet Ramey wrote:
> On 3/27/14 3:40 AM, Egmont Koblinger wrote:
> > Hi,
> >
> > Type a multiline command, and press ^C.
> >
> > bash-4.2: The new prompt appeared below the complete multiline command.
> >
> > bash-4.
On 3/27/14 3:40 AM, Egmont Koblinger wrote:
> Hi,
>
> Type a multiline command, and press ^C.
>
> bash-4.2: The new prompt appeared below the complete multiline command.
>
> bash-4.3: The new prompt appears right under the previous prompt,
> overwriting parts of the aborted command line and le
> Your response is "I recommend you to use 'set -x'"? Nice. Unfortunately it
> also means you're a troll, so further discussion with you is pointless.
>
Well, care to explain why I'm labeled as a troll?
I ran the following:
| bash-4.3$ mkdir a b c
| bash-4.3$ touch 1 2 3
| bash-4.3$
On Wednesday, March 26, 2014 8:30:12 PM UTC-4, billy...@gmail.com wrote:
> I tested on bash 4.3 and 3.0
>
>
>
> testing]$ bash --version
>
> bash --version
>
> GNU bash, version 4.3.0(1)-release (x86_64-unknown-linux-gnu)
>
>
>
> In a directory I have:
>
>
>
> testing]$ ls -l
>
> total
On Thu, Mar 27, 2014 at 08:19:39AM -0700, esoj wrote:
> I need to specify a variable path after #! but seems to me that bash can't
> do this.
> For example I need to specify the $HOME or ~ path as in:
>
>
> #!~/bin/python
> or
> #!$HOME/bin/python
This belongs on help-bash, not bug-bash. That s
Hi,
I was reading the bash manual at:
"If the program is a file beginning with #!, the remainder of the first line
specifies an interpreter for the pro‐
gram. The shell executes the specified interpreter on operating systems that
do not handle this executable format
themselves.|
I need to specif
On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger wrote:
> On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> > files=()
> > while IFS= read -r -d '' file; do
> > files+=("$file")
> > done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
>
> i've seen this construct duplicated so many times :
> These restrictions that you talk about are important, but you don't seem to
> hear me when I say "My filenames never have spaces". My directories never
> have spaces. I am meticulous about my filesystems. On one hand I realize
> you think you're being helpful to someone who has just started
On Wednesday, March 26, 2014 8:30:12 PM UTC-4, billy...@gmail.com wrote:
> I tested on bash 4.3 and 3.0
>
>
>
> testing]$ bash --version
>
> bash --version
>
> GNU bash, version 4.3.0(1)-release (x86_64-unknown-linux-gnu)
>
>
>
> In a directory I have:
>
>
>
> testing]$ ls -l
>
> total
On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> files=()
> while IFS= read -r -d '' file; do
> files+=("$file")
> done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
i've seen this construct duplicated so many times :(. i wish we had a native
option for it. maybe something like:
On Wed, Mar 26, 2014 at 09:02:02PM -0700, billyco...@gmail.com wrote:
> The original intention was to play a randomly sorted list of songs (except
> ABBA):
See http://mywiki.wooledge.org/BashFAQ/026
I would use an approach like this:
files=()
while IFS= read -r -d '' file; do
files+=("$file")
On Thu, Mar 27, 2014 at 3:16 AM, Dan Douglas wrote:
> I have such a function of course, but don't care to make every script depend
> on it.
Oh, and of course I'll still be using the wrapper. This is a feature for my
great grandchildren to use once Apple is out of business and the last Macs
(that
As I'm sure everybody knows, Bash is the only shell that supports indexed
arrays but maps the option for reading fields to -a rather than -A. I realize
that "read -A" was an unfortunate, confusing choice in contrast to "typeset
-a", but this is a feature that I use in almost every script, and would
Egmont Koblinger writes:
> Sorry, I wasn't clear enough.
>
> By "multiline" I mean a simple command that is so long (e.g. takes so many
> parameters) that it cannot fit into a single line. (You reach the right
> margin of your terminal and keep on typing.)
I can reproduce that, and the subsequen
Sorry, I wasn't clear enough.
By "multiline" I mean a simple command that is so long (e.g. takes so many
parameters) that it cannot fit into a single line. (You reach the right
margin of your terminal and keep on typing.)
On Thu, Mar 27, 2014 at 8:50 AM, Chris Down wrote:
> Egmont Koblinger w
Egmont Koblinger writes:
> Type a multiline command, and press ^C.
>
> bash-4.2: The new prompt appeared below the complete multiline command.
>
> bash-4.3: The new prompt appears right under the previous prompt,
> overwriting parts of the aborted command line and leaving garbage after the
> ne
Hi,
Type a multiline command, and press ^C.
bash-4.2: The new prompt appeared below the complete multiline command.
bash-4.3: The new prompt appears right under the previous prompt,
overwriting parts of the aborted command line and leaving garbage after the
new prompt.
I believe this is a reg
33 matches
Mail list logo
