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
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,
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
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 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 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
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
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
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 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
On Fri, Mar 29, 2013 at 5:18 PM, John Kearney wrote:
> Oh and FYI
> IFS=: read
> may change the global IFS on some shells I think.
> Mainly thinking of pdksh right now.
it seems ok on this netbsd machine:
PD KSH v5.2.14 99/07/13.2
IFS=f read
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
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
I just encountered the following behaviour. Set up a directory
structure like:
mkdir basedir
cd basedir
mkdir -p dir1/dir2
ln -s dir1/dir2 dir2link
cd dir2link
now, you're sitting in dir2link, and you type:
cd ../
and hit the Tab key. The possible completions are shown as 'dir1' and
'dir2link',
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
Marcel Giannelia wrote:
> The problem is that some commands are "smart" and "know" how you
> got to your current working dir -- bash knows that you're in a symlink
> and that the parent dir of the *symlink* (not the actual directory
> you're in) is 'basedir'.
>
> However, this is not the literal m
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
>>
17 matches
Mail list logo
