Prev: Says it all?
Next: Knode double-posting (was Re: OT: Newbie question: Currentdirectory in path?)
From: Jim Diamond on 17 Jul 2010 10:03
On 2010-07-16 at 23:35 ADT, Grant <omg(a)grrr.id.au> wrote:
> On Fri, 16 Jul 2010 22:51:14 -0300, Jim Diamond <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>
>>On 2010-07-16 at 18:54 ADT, Grant <omg(a)grrr.id.au> wrote:
>>> On Fri, 16 Jul 2010 11:21:01 -0300, Jim Diamond <Jim.Diamond(a)nospam.AcadiaU.ca> wrote:
>>
>>>>In my case I create a lot of programs which I run from the current
>>>>directory, so typing './' all the time would be a nuisance. I don't
>>>>let evil people have accounts on my personal machines, and I don't
>>>>spend a lot of time poking around in other directories on "public"
>>>>machines, so I'm willing to accept the risk. But certainly anyone who
>>>>rarely or never wants to execute a program in the current directory
>>>>might sleep better at night without '.' in their PATH.
>>>
>>> In an odd twist, I know the dot is sitting there on my user path, but
>>> I still put the ./ in front of scripts sitting in my home dir. Tab
>>> expansion then knows that you're seeking an executable file.
>>
>>?? Tab expansion works on my system with without using the './'.
>>Are you sure it doesn't work on your system (given that you have '.'
>>in your PATH)?
>
> Oh, it works fine, but if you put ./ in front, the tab expander
> ignores non-exec files, sometimes handy?

Grant,

maybe it isn't worth flogging this to death, but I am curious about
what you mean. Assuming you want the tab expansion feature (of, I
presume, bash) to expand the first token of a command line (i.e., the
program to run), then (at least in my tests) bash won't auto-complete
a non-executable file either with or without './'. Is something
different happening on your system?

Cheers.
Jim
From: Jim Diamond on 18 Jul 2010 20:08
On 2010-07-17 at 20:19 ADT, Grant <omg(a)grrr.id.au> wrote:
> On Sat, 17 Jul 2010 11:03:05 -0300, Jim Diamond <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>
>>On 2010-07-16 at 23:35 ADT, Grant <omg(a)grrr.id.au> wrote:
>>> On Fri, 16 Jul 2010 22:51:14 -0300, Jim Diamond <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>>
>>>>On 2010-07-16 at 18:54 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>>> On Fri, 16 Jul 2010 11:21:01 -0300, Jim Diamond <Jim.Diamond(a)nospam.AcadiaU.ca> wrote:
>>>>
>>>>>>In my case I create a lot of programs which I run from the current
>>>>>>directory, so typing './' all the time would be a nuisance. I don't
>>>>>>let evil people have accounts on my personal machines, and I don't
>>>>>>spend a lot of time poking around in other directories on "public"
>>>>>>machines, so I'm willing to accept the risk. But certainly anyone who
>>>>>>rarely or never wants to execute a program in the current directory
>>>>>>might sleep better at night without '.' in their PATH.
>>>>>
>>>>> In an odd twist, I know the dot is sitting there on my user path, but
>>>>> I still put the ./ in front of scripts sitting in my home dir. Tab
>>>>> expansion then knows that you're seeking an executable file.
>>>>
>>>>?? Tab expansion works on my system with without using the './'.
>>>>Are you sure it doesn't work on your system (given that you have '.'
>>>>in your PATH)?
>>>
>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>> ignores non-exec files, sometimes handy?
>>
>>Grant,
>>
>>maybe it isn't worth flogging this to death, but I am curious about
>>what you mean. Assuming you want the tab expansion feature (of, I
>>presume, bash) to expand the first token of a command line (i.e., the
>>program to run), then (at least in my tests) bash won't auto-complete
>>a non-executable file either with or without './'. Is something
>>different happening on your system?
>
> I should keep to my normal habit of providing an example ;)
>
> Here I've cd'd to particular dir that contains all the scripts
> and data files for reading the regional registrars and building
> a new IP to country code database. The update script is called
> 'refresh', oddly enough :)
>
> Without the ./, I get for 're<tab>':
>
> grant(a)deltree:~/ip2c$ re
> read rec rename resolveip
> readcd recode-sr-latin renice restorefont
> readelf red replace restorepalette
> readlink ref reset restoretextmode
> readmsg refer resize return
> readonly refresh resizecons rev
> readprofile remsync resolve_stack_dump revpath
>
> See? Junk from all over the filesystem :(
>
> But with the ./, I get exactly what I want, './re<tab>':
>
> grant(a)deltree:~/ip2c$ ./refresh
>
> Difference now is that the tab completion only looks in here for
> the executable -- hmm, perhaps I explained it poorly upthread?

Perhaps. When you said
>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>> ignores non-exec files, sometimes handy?
I think you should have said
ignores system programs, sometimes handy?
or maybe
ignores programs in $PATH, sometimes handy?

Anyway, I now know what you were talking about.

Cheers.
Jim
From: Grant on 18 Jul 2010 21:50
On Sun, 18 Jul 2010 21:08:59 -0300, Jim Diamond <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:

>On 2010-07-17 at 20:19 ADT, Grant <omg(a)grrr.id.au> wrote:
>> On Sat, 17 Jul 2010 11:03:05 -0300, Jim Diamond <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>
>>>On 2010-07-16 at 23:35 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>> On Fri, 16 Jul 2010 22:51:14 -0300, Jim Diamond <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>>>
>>>>>On 2010-07-16 at 18:54 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>>>> On Fri, 16 Jul 2010 11:21:01 -0300, Jim Diamond <Jim.Diamond(a)nospam.AcadiaU.ca> wrote:
>>>>>
>>>>>>>In my case I create a lot of programs which I run from the current
>>>>>>>directory, so typing './' all the time would be a nuisance. I don't
>>>>>>>let evil people have accounts on my personal machines, and I don't
>>>>>>>spend a lot of time poking around in other directories on "public"
>>>>>>>machines, so I'm willing to accept the risk. But certainly anyone who
>>>>>>>rarely or never wants to execute a program in the current directory
>>>>>>>might sleep better at night without '.' in their PATH.
>>>>>>
>>>>>> In an odd twist, I know the dot is sitting there on my user path, but
>>>>>> I still put the ./ in front of scripts sitting in my home dir. Tab
>>>>>> expansion then knows that you're seeking an executable file.
>>>>>
>>>>>?? Tab expansion works on my system with without using the './'.
>>>>>Are you sure it doesn't work on your system (given that you have '.'
>>>>>in your PATH)?
>>>>
>>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>>> ignores non-exec files, sometimes handy?
>>>
>>>Grant,
>>>
>>>maybe it isn't worth flogging this to death, but I am curious about
>>>what you mean. Assuming you want the tab expansion feature (of, I
>>>presume, bash) to expand the first token of a command line (i.e., the
>>>program to run), then (at least in my tests) bash won't auto-complete
>>>a non-executable file either with or without './'. Is something
>>>different happening on your system?
>>
>> I should keep to my normal habit of providing an example ;)
>>
>> Here I've cd'd to particular dir that contains all the scripts
>> and data files for reading the regional registrars and building
>> a new IP to country code database. The update script is called
>> 'refresh', oddly enough :)
>>
>> Without the ./, I get for 're<tab>':
>>
>> grant(a)deltree:~/ip2c$ re
>> read rec rename resolveip
>> readcd recode-sr-latin renice restorefont
>> readelf red replace restorepalette
>> readlink ref reset restoretextmode
>> readmsg refer resize return
>> readonly refresh resizecons rev
>> readprofile remsync resolve_stack_dump revpath
>>
>> See? Junk from all over the filesystem :(
>>
>> But with the ./, I get exactly what I want, './re<tab>':
>>
>> grant(a)deltree:~/ip2c$ ./refresh
>>
>> Difference now is that the tab completion only looks in here for
>> the executable -- hmm, perhaps I explained it poorly upthread?
>
>Perhaps. When you said
>>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>>> ignores non-exec files, sometimes handy?
>I think you should have said
> ignores system programs, sometimes handy?
>or maybe
> ignores programs in $PATH, sometimes handy?

Yes, persistence is good when you're after an explanation :)

Thanks for clarifying.
>
>Anyway, I now know what you were talking about.

That's good, 'cos I'll likely forget again.

Can you imagine the wonderfully concise, clear, unambiguous user
manuals I used to write? Mud, clear as.

Grant.
From: Loki Harfagr on 19 Jul 2010 13:01
Mon, 19 Jul 2010 11:50:09 +1000, Grant did cat :

> On Sun, 18 Jul 2010 21:08:59 -0300, Jim Diamond
> <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>
>>On 2010-07-17 at 20:19 ADT, Grant <omg(a)grrr.id.au> wrote:
>>> On Sat, 17 Jul 2010 11:03:05 -0300, Jim Diamond
>>> <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>>
>>>>On 2010-07-16 at 23:35 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>>> On Fri, 16 Jul 2010 22:51:14 -0300, Jim Diamond
>>>>> <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>>>>
>>>>>>On 2010-07-16 at 18:54 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>>>>> On Fri, 16 Jul 2010 11:21:01 -0300, Jim Diamond
>>>>>>> <Jim.Diamond(a)nospam.AcadiaU.ca> wrote:
>>>>>>
>>>>>>>>In my case I create a lot of programs which I run from the current
>>>>>>>>directory, so typing './' all the time would be a nuisance. I
>>>>>>>>don't let evil people have accounts on my personal machines, and I
>>>>>>>>don't spend a lot of time poking around in other directories on
>>>>>>>>"public" machines, so I'm willing to accept the risk. But
>>>>>>>>certainly anyone who rarely or never wants to execute a program in
>>>>>>>>the current directory might sleep better at night without '.' in
>>>>>>>>their PATH.
>>>>>>>
>>>>>>> In an odd twist, I know the dot is sitting there on my user path,
>>>>>>> but I still put the ./ in front of scripts sitting in my home dir.
>>>>>>> Tab expansion then knows that you're seeking an executable file.
>>>>>>
>>>>>>?? Tab expansion works on my system with without using the './'.
>>>>>>Are you sure it doesn't work on your system (given that you have '.'
>>>>>>in your PATH)?
>>>>>
>>>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>>>> ignores non-exec files, sometimes handy?
>>>>
>>>>Grant,
>>>>
>>>>maybe it isn't worth flogging this to death, but I am curious about
>>>>what you mean. Assuming you want the tab expansion feature (of, I
>>>>presume, bash) to expand the first token of a command line (i.e., the
>>>>program to run), then (at least in my tests) bash won't auto-complete
>>>>a non-executable file either with or without './'. Is something
>>>>different happening on your system?
>>>
>>> I should keep to my normal habit of providing an example ;)
>>>
>>> Here I've cd'd to particular dir that contains all the scripts and
>>> data files for reading the regional registrars and building a new IP
>>> to country code database. The update script is called 'refresh',
>>> oddly enough :)
>>>
>>> Without the ./, I get for 're<tab>':
>>>
>>> grant(a)deltree:~/ip2c$ re
>>> read rec rename resolveip
>>> readcd recode-sr-latin renice
>>> restorefont readelf red replace
>>> restorepalette readlink ref reset
>>> restoretextmode readmsg refer resize
>>> return readonly refresh resizecons
>>> rev readprofile remsync resolve_stack_dump
>>> revpath
>>>
>>> See? Junk from all over the filesystem :(
>>>
>>> But with the ./, I get exactly what I want, './re<tab>':
>>>
>>> grant(a)deltree:~/ip2c$ ./refresh
>>>
>>> Difference now is that the tab completion only looks in here for the
>>> executable -- hmm, perhaps I explained it poorly upthread?
>>
>>Perhaps. When you said
>>>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>>>> ignores non-exec files, sometimes handy?
>>I think you should have said
>> ignores system programs, sometimes handy?
>>or maybe
>> ignores programs in $PATH, sometimes handy?
>
> Yes, persistence is good when you're after an explanation :)
>
> Thanks for clarifying.
>>
>>Anyway, I now know what you were talking about.
>
> That's good, 'cos I'll likely forget again.
>
> Can you imagine the wonderfully concise, clear, unambiguous user manuals
> I used to write? Mud, clear as.

probably cristalline if compared to some projects comments I wrote in the 80s
until that day, perfect day, when I was put in charge of remodeling one
of these previous devs. After a few days of sweat, fever, and shakes struggling
my own ancient comments I finally almost fully made up the remodeling out of
the blue after rev-eng. the code but that time I added plain clear and contextual
as well as functional comments (at least I hope so) :D)
From: Grant on 19 Jul 2010 16:53
On 19 Jul 2010 17:01:32 GMT, Loki Harfagr <l0k1(a)thedarkdesign.free.fr.INVALID> wrote:

>Mon, 19 Jul 2010 11:50:09 +1000, Grant did cat :
>
>> On Sun, 18 Jul 2010 21:08:59 -0300, Jim Diamond
>> <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>
>>>On 2010-07-17 at 20:19 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>> On Sat, 17 Jul 2010 11:03:05 -0300, Jim Diamond
>>>> <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>>>
>>>>>On 2010-07-16 at 23:35 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>>>> On Fri, 16 Jul 2010 22:51:14 -0300, Jim Diamond
>>>>>> <Jim.Diamond(a)deletethis.AcadiaU.ca> wrote:
>>>>>>
>>>>>>>On 2010-07-16 at 18:54 ADT, Grant <omg(a)grrr.id.au> wrote:
>>>>>>>> On Fri, 16 Jul 2010 11:21:01 -0300, Jim Diamond
>>>>>>>> <Jim.Diamond(a)nospam.AcadiaU.ca> wrote:
>>>>>>>
>>>>>>>>>In my case I create a lot of programs which I run from the current
>>>>>>>>>directory, so typing './' all the time would be a nuisance. I
>>>>>>>>>don't let evil people have accounts on my personal machines, and I
>>>>>>>>>don't spend a lot of time poking around in other directories on
>>>>>>>>>"public" machines, so I'm willing to accept the risk. But
>>>>>>>>>certainly anyone who rarely or never wants to execute a program in
>>>>>>>>>the current directory might sleep better at night without '.' in
>>>>>>>>>their PATH.
>>>>>>>>
>>>>>>>> In an odd twist, I know the dot is sitting there on my user path,
>>>>>>>> but I still put the ./ in front of scripts sitting in my home dir.
>>>>>>>> Tab expansion then knows that you're seeking an executable file.
>>>>>>>
>>>>>>>?? Tab expansion works on my system with without using the './'.
>>>>>>>Are you sure it doesn't work on your system (given that you have '.'
>>>>>>>in your PATH)?
>>>>>>
>>>>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>>>>> ignores non-exec files, sometimes handy?
>>>>>
>>>>>Grant,
>>>>>
>>>>>maybe it isn't worth flogging this to death, but I am curious about
>>>>>what you mean. Assuming you want the tab expansion feature (of, I
>>>>>presume, bash) to expand the first token of a command line (i.e., the
>>>>>program to run), then (at least in my tests) bash won't auto-complete
>>>>>a non-executable file either with or without './'. Is something
>>>>>different happening on your system?
>>>>
>>>> I should keep to my normal habit of providing an example ;)
>>>>
>>>> Here I've cd'd to particular dir that contains all the scripts and
>>>> data files for reading the regional registrars and building a new IP
>>>> to country code database. The update script is called 'refresh',
>>>> oddly enough :)
>>>>
>>>> Without the ./, I get for 're<tab>':
>>>>
>>>> grant(a)deltree:~/ip2c$ re
>>>> read rec rename resolveip
>>>> readcd recode-sr-latin renice
>>>> restorefont readelf red replace
>>>> restorepalette readlink ref reset
>>>> restoretextmode readmsg refer resize
>>>> return readonly refresh resizecons
>>>> rev readprofile remsync resolve_stack_dump
>>>> revpath
>>>>
>>>> See? Junk from all over the filesystem :(
>>>>
>>>> But with the ./, I get exactly what I want, './re<tab>':
>>>>
>>>> grant(a)deltree:~/ip2c$ ./refresh
>>>>
>>>> Difference now is that the tab completion only looks in here for the
>>>> executable -- hmm, perhaps I explained it poorly upthread?
>>>
>>>Perhaps. When you said
>>>>>> Oh, it works fine, but if you put ./ in front, the tab expander
>>>>>> ignores non-exec files, sometimes handy?
>>>I think you should have said
>>> ignores system programs, sometimes handy?
>>>or maybe
>>> ignores programs in $PATH, sometimes handy?
>>
>> Yes, persistence is good when you're after an explanation :)
>>
>> Thanks for clarifying.
>>>
>>>Anyway, I now know what you were talking about.
>>
>> That's good, 'cos I'll likely forget again.
>>
>> Can you imagine the wonderfully concise, clear, unambiguous user manuals
>> I used to write? Mud, clear as.
>
>probably cristalline if compared to some projects comments I wrote in the 80s
>until that day, perfect day, when I was put in charge of remodeling one
>of these previous devs. After a few days of sweat, fever, and shakes struggling
>my own ancient comments I finally almost fully made up the remodeling out of
>the blue after rev-eng. the code but that time I added plain clear and contextual
>as well as functional comments (at least I hope so) :D)

:o)

Grant.
First  |  Prev  | 
Pages: 1 2 3
Prev: Says it all?
Next: Knode double-posting (was Re: OT: Newbie question: Currentdirectory in path?)