Re: [PD] [shell] on OSX...
Very cool, thanks to you both!
d.
Roman Haefeli wrote:
> On Thu, 2007-10-18 at 19:15 +0200, IOhannes m zmoelnig wrote:
>> Derek Holzer wrote:
>>> Hi IOhannes,
>>>
>>> IOhannes m zmoelnig wrote:
>>>
what you are sending to [shell] basically _is_ a shellscript...
>>> Ah, OK, now I see. I've been doing it the way you suggested, and as I
>>> reported it's painfully slow. Several degrees of ten times slower than
>>> the same commandline entered into an open terminal. Or even that opening
>>> a new terminal and then entering the command. I thought maybe there
>>> would be a way to make it faster.
>> #!/bin/bash
>> netreceive udp | while read line
>
> pdreceive udp | while read line # there is no 'netreceive' command
>
>> do
>> mkdir -p $(echo ${line} | sed -e 's|;$||')
>> done
>>
>> [symbol\
>> |
>> [send /home/derek/test_$1(
>> |
>> [netsend 1]
>
> yeah, nice example of a server. thanks
>
> roman
>
>
>
>
>
>
> ___
> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
> http://mail.yahoo.de
>
--
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 54:
"Do something sudden, destructive and unpredictable"
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [shell] on OSX...
On Thu, 2007-10-18 at 19:15 +0200, IOhannes m zmoelnig wrote:
> Derek Holzer wrote:
> > Hi IOhannes,
> >
> > IOhannes m zmoelnig wrote:
> >
> >> what you are sending to [shell] basically _is_ a shellscript...
> >
> > Ah, OK, now I see. I've been doing it the way you suggested, and as I
> > reported it's painfully slow. Several degrees of ten times slower than
> > the same commandline entered into an open terminal. Or even that opening
> > a new terminal and then entering the command. I thought maybe there
> > would be a way to make it faster.
>
> #!/bin/bash
> netreceive udp | while read line
pdreceive udp | while read line # there is no 'netreceive' command
> do
> mkdir -p $(echo ${line} | sed -e 's|;$||')
> done
>
> [symbol\
> |
> [send /home/derek/test_$1(
> |
> [netsend 1]
yeah, nice example of a server. thanks
roman
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
http://mail.yahoo.de
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [shell] on OSX...
Derek Holzer wrote:
> Hi IOhannes,
>
> IOhannes m zmoelnig wrote:
>
>> what you are sending to [shell] basically _is_ a shellscript...
>
> Ah, OK, now I see. I've been doing it the way you suggested, and as I
> reported it's painfully slow. Several degrees of ten times slower than
> the same commandline entered into an open terminal. Or even that opening
> a new terminal and then entering the command. I thought maybe there
> would be a way to make it faster.
#!/bin/bash
netreceive udp | while read line
do
mkdir -p $(echo ${line} | sed -e 's|;$||')
done
[symbol\
|
[send /home/derek/test_$1(
|
[netsend 1]
>
>> if it get's more complicated just do it like this
>>
>> #!/bin/sh
>> cd /home/derek
>> mkdir test_$1
>>
>> and call your script with [/path/to/myscript.sh $1(
>
> So simple bash scripts can use $1 as well? That was what I was unsure
> about. I thought there was other syntax to introduce variables into them
> that I *didn't* know.
it's the other way round: pd can use $1 as well, just like other
languages, including bash.
and what's more, $0 has a more logical meaning in bash...
fgnasdr.
IOhannes
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [shell] on OSX...
Hi IOhannes, IOhannes m zmoelnig wrote: > what you are sending to [shell] basically _is_ a shellscript... Ah, OK, now I see. I've been doing it the way you suggested, and as I reported it's painfully slow. Several degrees of ten times slower than the same commandline entered into an open terminal. Or even that opening a new terminal and then entering the command. I thought maybe there would be a way to make it faster. > if it get's more complicated just do it like this > > #!/bin/sh > cd /home/derek > mkdir test_$1 > > and call your script with [/path/to/myscript.sh $1( So simple bash scripts can use $1 as well? That was what I was unsure about. I thought there was other syntax to introduce variables into them that I *didn't* know. best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 104: "Listen in total darkness, or in a very large room, very quietly" ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [shell] on OSX...
Derek Holzer wrote: > I'm not so good at shell scripts, so bear with me for a second oh, and i forgot: what you are sending to [shell] basically _is_ a shellscript... so you basically know enough to write one that is just as simple as you require it. fma.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [shell] on OSX...
Derek Holzer wrote: > Hi IOhannes, > > thanks for the clarifications. I understand now why [shell] doesn't stay > in "/home/derek" between commands. > > I'm not so good at shell scripts, so bear with me for a second > > What I'd like to do is pass variables so, for example: > > cd /home/derek && mkdir test_$1 in this complicated example i would suggest to run "mkdir /home/derek/test_$1" :-) > > --where $1 is a number created by PD and sent to the shell script. The > dir name could be constructed by [nsprint], for example, as it may have > other variable as well. The shell script would only need a single > variable to receive the constructed dir name. > > Does that make sense? Is this easy to do? > if it get's more complicated just do it like this #!/bin/sh cd /home/derek mkdir test_$1 and call your script with [/path/to/myscript.sh $1( mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [shell] on OSX...
Hi IOhannes, thanks for the clarifications. I understand now why [shell] doesn't stay in "/home/derek" between commands. I'm not so good at shell scripts, so bear with me for a second What I'd like to do is pass variables so, for example: cd /home/derek && mkdir test_$1 --where $1 is a number created by PD and sent to the shell script. The dir name could be constructed by [nsprint], for example, as it may have other variable as well. The shell script would only need a single variable to receive the constructed dir name. Does that make sense? Is this easy to do? thx! d. IOhannes m zmoelnig wrote: > Derek Holzer wrote: >> ...is painfully slow! It takes minutes sometimes to execute a command >> that the terminal handles is a second or two. Why is that? Does anyone >> else have this problem? > > i cannot help you here, but most likely it is a problem with > initializing a context: > everytime you call shell, it will have to restart the shell-interpreter > which will take some time (when you start the terminal it also takes > some time...once the terminal is up and running it is faster, but you > don't get this with the [shell]) > > btw, this is the reasons why many often-used applications are often > re-written as daemons (e.g. i have a virus-scanner that usually get's > called from the cmdline to scan a file - this is too slow if you are > using it on a mailserver; therefore there is a daemonized version of the > scanner which is always running and which takes the data to be scanned > via a pipe) > > this is also one of the reasons i hardly ever use [shell] but usually > write a small shellscript server (using ./pdreceive) and send data to > this server via [netsend] (and vice versa) > i often find this more stable (and fun), but it is more complicated to > setup. > > >> Also, it doesn't seem to understand, for example "cd /home/derek", >> since a "pwd" command immediately after still lists "/" as the current >> dir. > > > what makes you think it doesn't understand? > whenever you call shell, it will open up a new context. > so when you send "cd /home/derek" it will changedir into /home/derek > (from /) and then quit. when you call "pwd" it will print the working > directory of a fresh context (which is /) > it is like when you open a terminal and do a "cd /usr/local" and then > open another terminal and do a "pwd"... > this behaviour is the same on all platforms. > > therefore you one usually uses scripts for more complex operations: > $ cat /tmp/doit.sh > #!/bin/sh > cd /home/derek > pwd > > and then do > [/tmp/doit.sh( > | > [shell] > > > > > > fmadsr. > IOhannes > -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 2: "A line has two sides" ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [shell] on OSX...
Derek Holzer wrote: > ...is painfully slow! It takes minutes sometimes to execute a command > that the terminal handles is a second or two. Why is that? Does anyone > else have this problem? i cannot help you here, but most likely it is a problem with initializing a context: everytime you call shell, it will have to restart the shell-interpreter which will take some time (when you start the terminal it also takes some time...once the terminal is up and running it is faster, but you don't get this with the [shell]) btw, this is the reasons why many often-used applications are often re-written as daemons (e.g. i have a virus-scanner that usually get's called from the cmdline to scan a file - this is too slow if you are using it on a mailserver; therefore there is a daemonized version of the scanner which is always running and which takes the data to be scanned via a pipe) this is also one of the reasons i hardly ever use [shell] but usually write a small shellscript server (using ./pdreceive) and send data to this server via [netsend] (and vice versa) i often find this more stable (and fun), but it is more complicated to setup. > Also, it doesn't seem to understand, for example > "cd /home/derek", since a "pwd" command immediately after still lists > "/" as the current dir. what makes you think it doesn't understand? whenever you call shell, it will open up a new context. so when you send "cd /home/derek" it will changedir into /home/derek (from /) and then quit. when you call "pwd" it will print the working directory of a fresh context (which is /) it is like when you open a terminal and do a "cd /usr/local" and then open another terminal and do a "pwd"... this behaviour is the same on all platforms. therefore you one usually uses scripts for more complex operations: $ cat /tmp/doit.sh #!/bin/sh cd /home/derek pwd and then do [/tmp/doit.sh( | [shell] fmadsr. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [shell] on OSX...
...is painfully slow! It takes minutes sometimes to execute a command that the terminal handles is a second or two. Why is that? Does anyone else have this problem? Also, it doesn't seem to understand, for example "cd /home/derek", since a "pwd" command immediately after still lists "/" as the current dir. Suggestions to speed it up/make it listen? OSX 10.4.10 PD-0.39.2-extended-test4 PD-0.39.2-extended-rc4 best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 105: "Listen to the quiet voice" ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
