On 3/29/13 11:18 AM, John Kearney wrote:
> Oh and FYI
> IFS=: read
> may change the global IFS on some shells I think.
Very few, if any.
> Mainly thinking of pdksh right now.
>
> IFS=: ls # local
>
> ls_wrap(){
> ls
> }
>
> IFS=: ls_wrap # Changes global IFS
>
> I think it was the same wi
John Kearney wrote:
> Am 29.03.2013 18:53, schrieb Linda Walsh:
>> Greg Wooledge wrote:
>>> On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
include was designed to search the path for functions that
are relative paths. While the normal sourcepath allows searching for
>>
Am 29.03.2013 18:53, schrieb Linda Walsh:
>
> Greg Wooledge wrote:
>> On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
>>> include was designed to search the path for functions that
>>> are relative paths. While the normal sourcepath allows searching for
>>> filenames on the search
Greg Wooledge wrote:
> On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
>> include was designed to search the path for functions that
>> are relative paths. While the normal sourcepath allows searching for
>> filenames on the search path, I don't believe (please correct if I am
Am 29.03.2013 16:36, schrieb Greg Wooledge:
> On Fri, Mar 29, 2013 at 04:10:22PM +0100, John Kearney wrote:
>> consider
>> dethrophes@dethace ~
>> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>>
>> dethrophes@dethace ~
>> $ echo ${vals[0]}
>> lkjlksda
> You forgot to set IFS=: for that r
On Fri, Mar 29, 2013 at 04:10:22PM +0100, John Kearney wrote:
> consider
> dethrophes@dethace ~
> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>
> dethrophes@dethace ~
> $ echo ${vals[0]}
> lkjlksda
You forgot to set IFS=: for that read.
imadev:~$ IFS=: read -ra vals -d '' <<< $'lkjlk
Am 29.03.2013 16:23, schrieb Pierre Gaston:
> On Fri, Mar 29, 2013 at 5:10 PM, John Kearney wrote:
>> consider
>> dethrophes@dethace ~
>> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>>
>> dethrophes@dethace ~
>> $ echo ${vals[0]}
>> lkjlksda
>>
>> I meant to update your wiki about it b
On Fri, Mar 29, 2013 at 5:10 PM, John Kearney wrote:
> consider
> dethrophes@dethace ~
> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>
> dethrophes@dethace ~
> $ echo ${vals[0]}
> lkjlksda
>
> I meant to update your wiki about it but I forgot.
> I guess read uses gets not fread and tha
Oh and FYI
IFS=: read
may change the global IFS on some shells I think.
Mainly thinking of pdksh right now.
IFS=: ls # local
ls_wrap(){
ls
}
IFS=: ls_wrap # Changes global IFS
I think it was the same with builtins, but not sure right now.
Thats why I always use wrapper functions and local
Am 29.03.2013 15:30, schrieb Greg Wooledge:
> On Fri, Mar 29, 2013 at 03:11:07PM +0100, John Kearney wrote:
>> Actually I've had trouble
>>
>> IFS=: read -ra paths <<< "$PATH"
>>
>> and embedded new lines.
> A directory with a newline in its name, in your PATH? Terrifying.
why not :) its a great w
On Fri, Mar 29, 2013 at 03:11:07PM +0100, John Kearney wrote:
> Actually I've had trouble
>
> IFS=: read -ra paths <<< "$PATH"
>
> and embedded new lines.
A directory with a newline in its name, in your PATH? Terrifying.
> I think this is better
> find_file() {
> local IFS=:
> for dir
Am 29.03.2013 12:57, schrieb Greg Wooledge:
> On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
>> include was designed to search the path for functions that
>> are relative paths. While the normal sourcepath allows searching for
>> filenames on the search path, I don't believe (pl
On 03/29/2013 12:57 PM, Greg Wooledge wrote:
> On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
>> include was designed to search the path for functions that
>> are relative paths. While the normal sourcepath allows searching for
>> filenames on the search path, I don't believe (p
On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
> include was designed to search the path for functions that
> are relative paths. While the normal sourcepath allows searching for
> filenames on the search path, I don't believe (please correct if I am wrong
> and this works now,
Dan Douglas wrote:
> Can you whittle this down to the smallest reproducer and post a stand-alone
> synthetic testcase with sample input data that fails?
If I had a clue how to do that, I would, that's why I mentioned
that that **NORMALLY** it works fine.
include was designe
Can you whittle this down to the smallest reproducer and post a stand-alone
synthetic testcase with sample input data that fails?
If the goal is simulating "exported arrays", there are other methods that
would probably work out better.
--
Dan Douglas
Greg Wooledge wrote:
> On Wed, Mar 27, 2013 at 02:37:16PM -0700, Linda Walsh wrote:
>> Greg Wooledge wrote:
> Array variables may not (yet) be exported.
>>> Associative arrays can't be exported either.
>
>> Yeah, but they seem to get propagated anyway, I must save it somewhere
>>
On Wed, Mar 27, 2013 at 02:37:16PM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> >>> Array variables may not (yet) be exported.
> > Associative arrays can't be exported either.
> Yeah, but they seem to get propagated anyway, I must save it somewhere
> like
> I do _FPATH... i.e. e
Greg Wooledge wrote:
> On Wed, Mar 27, 2013 at 01:25:53PM -0700, Linda Walsh wrote:
>> Greg Wooledge wrote:
>>> Arrays cannot be exported. The bash manual explicitly says so:
>>>
>>> Array variables may not (yet) be exported.
>> ===
>> It is there for the 'yet' part. In "aliases.sh" w
On Wed, Mar 27, 2013 at 01:25:53PM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> > Arrays cannot be exported. The bash manual explicitly says so:
> >
> > Array variables may not (yet) be exported.
> ===
> It is there for the 'yet' part. In "aliases.sh" which
> defines the 'includ
Greg Wooledge wrote:
> On Wed, Mar 27, 2013 at 12:17:21PM -0700, Linda Walsh wrote:
>> dcl -x _SPATH
>> dcl -xa _FPATH
>> dcl -xA _INC
>
> Arrays cannot be exported. The bash manual explicitly says so:
>
> Array variables may not (yet) be exported.
===
It is there for the 'yet' p
On Wed, Mar 27, 2013 at 12:17:21PM -0700, Linda Walsh wrote:
> dcl -xa _FPATH
Arrays cannot be exported. The bash manual explicitly says so:
Array variables may not (yet) be exported.
> } | ( ((!(remove||expire))) && hsort -s || cat)
Use of the && and || operators together as a "shorthan
Greg Wooledge wrote:
> We would need to see the definition of the "include" function, and the
> contents of the file that it's presumably sourcing or whatever.
>
Working on packaging, but to answer your immediate questions:
Assuming attachments work, 'include' is in ~/bin
Note, some of these fi
On Wed, Mar 27, 2013 at 11:29:38AM -0700, Linda Walsh wrote:
> include lib/Util/Needroot.shh
>
> where include is a function the name of a file in my path (or an alias
> to define the function)...
>
>
> /home/law/bin/recycle_space: line 7: lib/Util/needroot.shh: division by
> 0 (error token is "
Not sure if this is the correct forum for this, as I am very uncertain
that it is a bash-bug and am more inclined to believe it is some
odd interpretation causing my code to go hay-wire in this instance.
So if I should move this to another discussion location, I'm fine
with that -- I'm just trying
25 matches
Mail list logo
