...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 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
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 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
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 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 9999 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
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 9999 udp | while read line
pdreceive 9999 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
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 9999 udp | while read line
pdreceive 9999 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 -
IOhannes m zmoelnig -
Roman Haefeli