>
> > also this variant does the same:
> > $ (('ar[$idbad2]+=11'))
> Because (( and let are essentially equivalent.
I think the more important question isn't "why does (( behave this way?",
but rather "should (( behave this way?".
It's probably not reasonable to expect the author to know and t
rmat modifier? Does bash re-implement printf or does it use the
Standard C Library's printf? (If the former; why?)
--
*Maarten Billemont* (lhunath)
me: http://www.lhunath.com – business: http://www.lyndir.com –
http://masterpasswordapp.com
> [0]=b -- because we mutate the array by
setting the element to that given.
indexed_array=( [0]+=b ) #=> [0]=b -- because we unset the array and set
the element by appending the given to nothing.
indexed_array+=( [0]+=b ) #=> [0]=bb -- because we mutate the array by
appending the given to what is already there.
--
*Maarten Billemont* (lhunath)
me: http://www.lhunath.com – business: http://www.lyndir.com –
http://masterpasswordapp.com
On Jun 2, 2014, at 9:34 AM, Greg Wooledge wrote:
> On Mon, Jun 02, 2014 at 03:08:17PM +0200, Andreas Schwab wrote:
>> Greg Wooledge writes:
>>
>>> imadev:~$ : $((a[$x]))
>>> bash: Mon Jun 2 08:06:39 EDT 2014: syntax error in expression (error token
>>> is "Jun 2 08:06:39 EDT 2014")
>>>
>>> Th
the exit handler is called, you just muted it. remove the redirections,
and you'll also notice you need a space after your !
On 16 May 2014 12:41, Mark Ferrell wrote:
> The following script properly reports the exit code to the calling
> environment, , but the exit handler is not called if a f
Trapping on EXIT is a really convenient way of cleaning up after yourself when
your script ends.
The nice thing about it is that you don't need to handle all sorts of signals,
handle them, and re-throw them. It makes for a single clean point to define
your exit handlers.
Unfortunately, I've n
able input and
where you don't always notice breakage until it's caused irreparable harm. I
don't really care what lame justifications you come up with to try and justify
broken system code to yourself, just don't try to convince us with them.
> Maarten Billemont wrote:
On 26 Apr 2012, at 06:30, John Kearney wrote:
> Am 26.04.2012 06:26, schrieb Linda Walsh:
>> I know I can get
>> a="abcdef" echo "${a[2:4]}" = cde
>>
>> how do I do:
>> typeset -a a=(apple berry cherry date); then get:
>>
>> echo ${a[1:2]} = "berry" "cherry" ( non-grouped args)
>>
>> I tried to
On 26 Apr 2012, at 01:18, Linda Walsh wrote:
>
> Ishtar:> echo "${b[*]}"
Please note that expanding array elements using [*] is usually NOT what anyone
wants. Be careful about recommending it to anyone.
"${b[*]}" # This throws away any usefulness of the array by merging all the
array elements
On 16 Apr 2012, at 11:43, Linda Walsh wrote:
>
>
> But it won't work for files below the top level of the library directory.
>
> if I have include system/errno.shh, Source is crippled to not look in PATH.
When there's a slash in the file, it stops searching PATH.
So the reason you're not doi
On 16 Apr 2012, at 09:54, Maarten Billemont wrote:
> On 15 Apr 2012, at 22:52, Linda Walsh wrote:
>>
>> But I want the syntax
>>
>> include file.shh
>>
>> to just 'work', i.e. first time, it would call my include file, which defines
>> the
On 15 Apr 2012, at 22:52, Linda Walsh wrote:
>
> But I want the syntax
>
> include file.shh
>
> to just 'work', i.e. first time, it would call my include file, which defines
> the function...
I'm sorry, tell me again why you don't just write "source file.sh" instead of
having to invent your ow
On 15 Apr 2012, at 03:21, Chet Ramey wrote:
>
> If I declare a variable readonly at global scope, I wouldn't expect it
> to be overridden by some local namespace pollution.
I think that's fine; in the local context, your variable has a different
meaning; it's another variable with the same name.
On 10 Apr 2012, at 08:26, Barry Margolin wrote:
>
> if [ $status = 0 ]
As an aside, I don't think it's a good idea to recommend comparing numbers
using string comparison operators.
if (( status == 0 ))
But if you wanted to treat them as strings for the sake of code simplicity,
just go the cas
On 09 Apr 2012, at 11:46, Linda Walsh wrote:
>
> Like it costs how much? I would **bet** that it cost more code to support
> (()) than to support [] as arith ops .. so if you want my opinion, lets toss
> (())...
> (like that'll happen)...
Just thought I'd add that I personally prefer $((...))
On 10 Apr 2012, at 06:03, Elliott Forney wrote:
> Here is another example that appears to defy my expectations. In this
> case, the semicolon is allowed:
>
> sine:~$ hello='echo hello'
> sine:~$ world='echo world'
> sine:~$ ${hello};${world}
> hello
> world
> sine:~$ unset hello
> sine:~$ ${hello
On 08 Apr 2012, at 21:30, Chet Ramey wrote:
> On 4/8/12 3:02 PM, Maarten Billemont wrote:
>
>> Any particular reason for not removing old undocumented functionality, or is
>> that mostly the nature of this beast - dragging along and maintaining
>> ancient code for t
On 08 Apr 2012, at 01:47, Chet Ramey wrote:
> On 4/7/12 4:45 PM, Linda Walsh wrote:
>>
>>
>>
>> In modifying some released code on my distro,I ran into the extensive use
>> of $[arith] as a means for returning arithmetic evaluations of the
>> expression.
>>
>> I vaguely remember somethin
On 28 Feb 2012, at 23:23, Chet Ramey wrote:
> On 2/28/12 5:18 PM, John Kearney wrote:
>> On 02/28/2012 11:07 PM, Chet Ramey wrote:
>>> On 2/28/12 4:28 PM, John Kearney wrote:
On 02/28/2012 10:05 PM, Chet Ramey wrote:
> On 2/28/12 12:26 PM, John Kearney wrote:
>
>> But that i
On 28 Feb 2012, at 18:52, John Kearney wrote:
> On 02/28/2012 06:43 PM, Dan Douglas wrote:
>> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
>>> On 02/28/2012 06:31 PM, Dan Douglas wrote:
On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
> On 02/28/2012 05:49 PM,
On 05 Aug 2011, at 16:32, Steven W. Orr wrote:
> On 8/5/2011 9:08 AM, Maarten Billemont wrote:
>>> IFS=
>>> aa=()
>>> while read line
>>> do
>>> aa+=("$line")
>>> done< fn
>>
>> You should really put that IFS
> IFS=
> aa=()
> while read line
> do
> aa+=("$line")
> done < fn
You should really put that IFS= on your 'read', so as not to break the default
wordsplitting for the rest of your script:
while IFS= read -r line
> vs.
> IFS=$'\n'
> aa=($(< fn))
Don't leave expansions unquoted! you're still p
In the following snippet, I expect the two ls' to give the same output.
However, it appears the process substitution's temporary file sometimes
vanishes for the second. Can someone explain why and whether this is the
desired behavior or not?
A Linux (2.6.27.6) VM in a QEMU says this:
# moo()
On 30/06/11 14:15, Greg Wooledge wrote:
> On Wed, Jun 29, 2011 at 06:41:25PM +0200, Maarten Billemont wrote:
>> For those to whom a cursor between elements seems confusing: think
of your prompt's cursor and imagine an element is a single character.
>
> No wonder this makes n
On 29 Jun 2011, at 15:01, Greg Wooledge wrote:
>
> On Wed, Jun 29, 2011 at 01:42:06PM +0200, Maarten Billemont wrote:
>> If you expand ${arr[@]:1:2}, you get the following:
>> values: [ a | b | c ]
>> indexes: 0 1 2 3
>> expand: [ 1 2 ] =>
On 29 Jun 2011, at 14:05, Mart Frauenlob wrote:
>
> On 29.06.2011 13:42, Maarten Billemont wrote:
>> On 27 Jun 2011, at 16:25, Chet Ramey wrote:
>>>
> [...]
>> Exactly, let's draw the array in the example:
>>
>> arr=(a b c)
>> values: [ a |
> Since ${arr[-1]} already does exactly this, I figure it would merely add to
> the syntax' consistency.
Consider the fact that ${arr[x]} is in fact the equivalent of ${arr[@]:x:1}.
On 27 Jun 2011, at 16:25, Chet Ramey wrote:
>
>> I don't even understand what the second one is supposed to mean at
>> all -- the :1: means to start with "b" and the -2 means to go back 2
>> elements...? How do you derive "a c" from any possible interpretation
>> of this?
>
> I assume that he wa
On 13 May 2011, at 20:07, DJ Mills wrote:
> A -0 option, or even an option to use a different field separator, would be
> an
> excellent feature for mapfile. Currently, of course, you can use:
>
> while IFS= read -rd '' file; do array+=("$file"); done
>
> mapfile is considerably faster, however
On 23 Mar 2011, at 21:28, Chet Ramey wrote:
>
> OK. What wording would you like to see?
I don't mind the wording he proposed:
On 23 Mar 2011, at 17:12, Sam Liddicott wrote:
>maybe it should say
>
>BASH_SUBSHELL
> Incremented by one in each nested subshell or sub
On 23 Mar 2011, at 21:15, Sam Liddicott wrote:
>
> On 23/03/11 18:52, Chris F.A. Johnson wrote:
>>
>> On Wed, 23 Mar 2011, Sam Liddicott wrote:
>>
>>>
>>> Configuration Information [Automatically generated, do not change]:
>>> Machine: i686
>>> OS: linux-gnu
>>> Compiler: gcc
>>> Compilation
On 10 Mar 2011, at 15:23, Chet Ramey wrote:
>
> On 3/10/11 8:14 AM, Greg Wooledge wrote:
>> On Thu, Mar 10, 2011 at 10:18:26AM +0800, Clark J. Wang wrote:
>>> Actually I don't like the recursion here. Does POSIX require that?
>>>
For example:
unset a; declare a="a"; [[ a -lt 3 ]];
On 17 Feb 2011, at 23:02, Chet Ramey wrote:
>
>>>
>>> "Clark J. Wang" writes:
>>>
I think char `:' is not special in bash.
>>>
>>> $ printf "%q\n" "$COMP_WORDBREAKS"
>>> $' \t\n"\'><=;|&(:'
>>>
>>>
>> I don't think that explain the issue.
>
>
On 12 Feb 2011, at 11:57, Ralf Goertz wrote:
>
> Hi,
>
> I am wondering what the reasoning might be for this seeming
> inconsistence.
>
>> i=08
>> if [ $i -lt 9 ] ; then echo ok; fi
> ok
>> if [ $((i)) -lt 9 ] ; then echo ok; fi
> bash: 08: value too great for base (error token is "08")
>
> Why
On 12 Feb 2011, at 09:28, Andreas Schwab wrote:
>
> Bob Proulx writes:
>
>> Dennis Williamson wrote:
>>> Yes, do your quoting like this:
>>> ssh localhost 'bash -c "cd /tmp; pwd"'
>>
>> I am a big fan of piping the script to the remote shell.
>>
>> $ echo "cd /tmp && pwd" | ssh example.com ba
On 10 Feb 2011, at 15:21, Chet Ramey wrote:
>
> On 2/10/11 4:03 AM, Clark J. Wang wrote:
>> help: help [-dms] [pattern ...]
>>
>> From my understanding the *pattern* here must be a glob-style pattern
>> (wildcard) so `readonly' does not match the pattern `read'.
>
> The pattern is composed of th
On 05 Feb 2011, at 17:09, Andreas Schwab wrote:
>
> Maarten Billemont writes:
>
>> The comment is called a hashbang or shebang. It tells the kernel which
>> program to start. Your script is passed over stdin to the interpreter.
>
> No, it isn't, it's
On 05 Feb 2011, at 13:57, ali hagigat wrote:
>
> #!/bin/sh
> echo ppp
> echo $SHELL
> exit 2200
>
> In the above script i tried to specify /bin/sh as my parser by a
> comment. Is that OK? When I type ./scr2 , i want bash recognize
> /bin/sh as the parser of ./scr2.
>
The comment is called a
On 05 Feb 2011, at 13:47, ali hagigat wrote:
>
> if (sh -c exit 34) then echo p;fi
> p
> The following condition should be false, because our exit value is
> non-zero. but 'if' considers the condition as true and executes 'echo'
> command. Why?
>
You are giving -c the argument 'e
On 25 Nov 2009, at 14:58, Antonio Macchi wrote:
> my goal is very very stupid, like this
>
> $ printf "%q" $(
> to get a "ascii form" of a binary file (something like uuencode)
>
>
> but, as you can see, it does not work only for two binary chars
>
> 0x00, and 0x0a
That doesn't sound like a
You can "output" $'\x00' just fine:
$ printf '\0'
Note that -d $'\x00' is the same thing as -d '', for the reason I mentioned
earlier. The argument to the -d option that "read" takes is a C-string.
Understand the difference between *strings* and *streams*. A stream (standard
output of print
As for NUL out outputting anything in your result, the cause is C-strings.
Arguments are C-strings and those are delimited by NUL bytes. Therefore, the
NUL byte that you're putting in it is actually marking the end of the string.
So the argument ends BEFORE your NUL byte. So it's empty.
As
42 matches
Mail list logo
