Prev: Nail mailrc save/write 'no active mailbox'
Next: ls with creation time
From: Kaz Kylheku on 4 Dec 2009 16:23
On 2009-12-04, Chris F.A. Johnson <cfajohnson(a)gmail.com> wrote:
> On 2009-12-03, Kaz Kylheku wrote:
>> On 2009-12-03, Chris F.A. Johnson <cfajohnson(a)gmail.com> wrote:
>>> On 2009-12-03, Rakesh Sharma wrote:
>>>> On Dec 3, 7:16?am, Dave <f...(a)coo.com> wrote:
>>>>> The output of a command is this
>>>>>
>>>>> /opt/kirkby/gcc-4.4.2/lib/libgcc_s.so.1
>>>>>
>>>>> how can I strip off the path, and so just get the 'libgcc_s.so.1' ?
>>>>>
>>>>> I guess I need to strip from the first character, to the last '/', but are not
>>>>> sure how to do this.
>>>>>
>>>>
>>>> Apart from the command 'basename' which is tailor-made for this task,
>>>
>>> As is POSIX parameter expansion.
>>
>> Not sure why you ned to invoke POSIX here; basename is a also a POSIX feature,
>> and not a recent addition either.
>
> An external command such as basename is many, many times slower
> than the shell's parameter expansion.

That's an implementation problem, isn't it.

Some systems have command interpreters which provide fast built-in commands for
things which are external on some other systems.

Yes, you /can/ be quite sure that something like parameter expansion is done in
the same process. Plus anything which manipulates the environment and /cannot/
be a child program, like ``chdir''.

To me, it's a premature optimization. If basename isn't being used in some
hotspot in the code, it's not worth worrying about.

If a particular basename call ends up in a hotspot, then you can just fix
/that/ instance of it, not every single basename everywhere.

Efficiency is not a high priority in shell programming. If the shell
programming community cared about efficiency, there would be a wide-spread use
of shell script compilation.

A shell script compiler could turn your basename calls as well as
parameter expansion into efficient C,

Can you form a viable start-up company around a shell script compiler?
I suspect not, because nobody cares about such a thing.

Comeau Computing offers a shell script compiler. Could the business
stay afloat just on that product alone, I wonder. It would be interesting to
see what is the revenue from that.
From: pk on 4 Dec 2009 16:35
Kaz Kylheku wrote:

>> An external command such as basename is many, many times slower
>> than the shell's parameter expansion.
>
> That's an implementation problem, isn't it.
>
> Some systems have command interpreters which provide fast built-in
> commands for things which are external on some other systems.
>
> Yes, you /can/ be quite sure that something like parameter expansion is
> done in the same process. Plus anything which manipulates the environment
> and /cannot/ be a child program, like ``chdir''.

(I'm sure ou mean "cd" here, not "chdir")

POSIX mandates that conforming systems provide "cd" and other "built-in"
utilities as external commands (or, more exactly, that they provide a way to
exec() them). Some real word OSes - not Linux - indeed have a /bin/cd
command. It even provides more or less sensible use cases for it:


find . -type d -exec cd {} \; -exec foo {} \;
(which invokes "foo" on accessible directories)

From: Chris F.A. Johnson on 5 Dec 2009 18:15
On 2009-12-04, Kaz Kylheku wrote:
> On 2009-12-04, Chris F.A. Johnson <cfajohnson(a)gmail.com> wrote:
>> On 2009-12-03, Kaz Kylheku wrote:
>>> On 2009-12-03, Chris F.A. Johnson <cfajohnson(a)gmail.com> wrote:
>>>> On 2009-12-03, Rakesh Sharma wrote:
>>>>> On Dec 3, 7:16?am, Dave <f...(a)coo.com> wrote:
>>>>>> The output of a command is this
>>>>>>
>>>>>> /opt/kirkby/gcc-4.4.2/lib/libgcc_s.so.1
>>>>>>
>>>>>> how can I strip off the path, and so just get the 'libgcc_s.so.1' ?
>>>>>>
>>>>>> I guess I need to strip from the first character, to the last '/', but are not
>>>>>> sure how to do this.
>>>>>>
>>>>>
>>>>> Apart from the command 'basename' which is tailor-made for this task,
>>>>
>>>> As is POSIX parameter expansion.
>>>
>>> Not sure why you ned to invoke POSIX here; basename is a also a POSIX feature,
>>> and not a recent addition either.
>>
>> An external command such as basename is many, many times slower
>> than the shell's parameter expansion.
>
> That's an implementation problem, isn't it.

Yes, and I avoid the problem by using something that isn't affected
by it.

> Some systems have command interpreters which provide fast built-in commands for
> things which are external on some other systems.
>
> Yes, you /can/ be quite sure that something like parameter expansion is done in
> the same process. Plus anything which manipulates the environment and /cannot/
> be a child program, like ``chdir''.
>
> To me, it's a premature optimization. If basename isn't being used in some
> hotspot in the code, it's not worth worrying about.

I use parameter expansion, and therefore I don't have to worry
about whether it is a hotspot or not.

> If a particular basename call ends up in a hotspot, then you can just fix
> /that/ instance of it, not every single basename Everywhere.

I avoid the problem altogether by not using basename.

> Efficiency is not a high priority in shell programming. If the shell
> programming community cared about efficiency, there would be a wide-spread use
> of shell script compilation.

On the contrary, I find it very important. An efficiently written
script doesn't need to be compiled.


--
Chris F.A. Johnson, author <http://shell.cfajohnson.com/>
===================================================================
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
===== My code in this post, if any, assumes the POSIX locale =====
===== and is released under the GNU General Public Licence =====
From: David Combs on 19 Dec 2009 21:59
In article <4b171f83(a)212.67.96.135>, Dave <foo(a)coo.com> wrote:
>The output of a command is this
>
>/opt/kirkby/gcc-4.4.2/lib/libgcc_s.so.1
>
>how can I strip off the path, and so just get the 'libgcc_s.so.1' ?
>
>I guess I need to strip from the first character, to the last '/', but are not
>sure how to do this.

Mandatory reading:

Mastering Regular Expressions, 2nd ed, by Jeffrey Friedl.

Although the adjacent post has a good way to solve your
specific problem, you need to learn about regular expressions.

And man have they gotten FAR more powerful since the days
of Bell Labs.

There is one and ONLY one book, the "bible" of regular expressions,
so to speak, and it is that "Mastering" book.

He not only shows you the zillion features they have these
days, but he has lots of examples.

But what shows that he is THE expert on regular-expressions
is that he shows the internal MACHINERY that drives the
things. At least lots of it.

No, do not buy the "cookbook" until AFTER you have devoured
THIS book first.

Trust me, friend -- regular expressions are what make unix/linux
so useful. And no, they're not all that trivially simple,
but man are they POWERFUL. One line can transform stuff
that would take a complicated MULTI-line program NOT using them.


Cheers!

David

(No, I am no expert in them, but I do have the book, and
with that, I can do what I need to do.)



From: Chris F.A. Johnson on 19 Dec 2009 23:21
On 2009-12-20, David Combs wrote:
> In article <4b171f83(a)212.67.96.135>, Dave <foo(a)coo.com> wrote:
>>The output of a command is this
>>
>>/opt/kirkby/gcc-4.4.2/lib/libgcc_s.so.1
>>
>>how can I strip off the path, and so just get the 'libgcc_s.so.1' ?
>>
>>I guess I need to strip from the first character, to the last '/', but are not
>>sure how to do this.
>
> Mandatory reading:
>
> Mastering Regular Expressions, 2nd ed, by Jeffrey Friedl.
>
> Although the adjacent post has a good way to solve your
> specific problem, you need to learn about regular expressions.
>
> And man have they gotten FAR more powerful since the days
> of Bell Labs.
>
> There is one and ONLY one book, the "bible" of regular expressions,
> so to speak, and it is that "Mastering" book.
>
> He not only shows you the zillion features they have these
> days, but he has lots of examples.
>
> But what shows that he is THE expert on regular-expressions
> is that he shows the internal MACHINERY that drives the
> things. At least lots of it.
>
> No, do not buy the "cookbook" until AFTER you have devoured
> THIS book first.
>
> Trust me, friend -- regular expressions are what make unix/linux
> so useful. And no, they're not all that trivially simple,
> but man are they POWERFUL. One line can transform stuff
> that would take a complicated MULTI-line program NOT using them.

I very rarely use anything more than very simple regular
expressions. Complex REs are more trouble than they're worth,
especially when they need to be modified.


--
Chris F.A. Johnson, author <http://shell.cfajohnson.com/>
===================================================================
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
===== My code in this post, if any, assumes the POSIX locale =====
===== and is released under the GNU General Public Licence =====
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Nail mailrc save/write 'no active mailbox'
Next: ls with creation time