pharo bash script with startup
Hi, I just installed pharo 6.1 using the .zip file ( http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments. The issue is that the pharo bash script (in the extracted home dir) quotes all arguments: # execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image" where image = $* The impact is that if I want to run a startup script, eg. pharo my.image startup.st pharo complains with "Could not open the Pharo image file: 'my.image startup.st' So I must run the executable directly? If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this? Thanks Otto
Iâve not noticed that problem on ubuntu or AWS lambda so there must be something different going on. Sent from my iPhone
On 27 Jun 2018, at 07:30, Otto Behrens <otto@finworks.biz> wrote:
Hi,
I just installed pharo 6.1 using the .zip file (http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments.
The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image"
where
image = $*
The impact is that if I want to run a startup script, eg.
pharo my.image startup.st
pharo complains with "Could not open the Pharo image file: 'my.image startup.st'
So I must run the executable directly?
If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this?
Thanks Otto
Try with ./pharo or try with an absolute image path. On Wed, Jun 27, 2018, 04:03 Tim Mackinnon <tim@testit.works> wrote:
Iâve not noticed that problem on ubuntu or AWS lambda so there must be something different going on.
Sent from my iPhone
On 27 Jun 2018, at 07:30, Otto Behrens <otto@finworks.biz> wrote:
Hi,
I just installed pharo 6.1 using the .zip file ( http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments.
The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image"
where
image = $*
The impact is that if I want to run a startup script, eg.
pharo my.image startup.st
pharo complains with "Could not open the Pharo image file: 'my.image startup.st'
So I must run the executable directly?
If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this?
Thanks Otto
I am running with an absolute image path. The issue is definitely exec "$image" in the script. If I remove the "", i.e. exec $image, then it works. /opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image startup.st" gives me the same problem On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri <serpi90@gmail.com> wrote:
Try with ./pharo or try with an absolute image path.
On Wed, Jun 27, 2018, 04:03 Tim Mackinnon <tim@testit.works> wrote:
Iâve not noticed that problem on ubuntu or AWS lambda so there must be something different going on.
Sent from my iPhone
On 27 Jun 2018, at 07:30, Otto Behrens <otto@finworks.biz> wrote:
Hi,
I just installed pharo 6.1 using the .zip file (http://files.pharo.org/ platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments.
The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image"
where
image = $*
The impact is that if I want to run a startup script, eg.
pharo my.image startup.st
pharo complains with "Could not open the Pharo image file: 'my.image startup.st'
So I must run the executable directly?
If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this?
Thanks Otto
That's strange, is this a new problem or you always had it? I've just tested it, pharo 61 64 bits. $ wget -O - https://get.pharo.org/64/61+vm | bash [SNIP] $ ./pharo Pharo.image eval 1+1 2 Maybe the so called starter scripts (pharo, pharo-ui) are not the same using zeroconf and by downloading a plain vm like that? On Wed, Jun 27, 2018 at 9:38 AM Otto Behrens <otto@finworks.biz> wrote:
I am running with an absolute image path.
The issue is definitely exec "$image" in the script. If I remove the "", i.e. exec $image, then it works.
/opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image startup.st"
gives me the same problem
On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri <serpi90@gmail.com> wrote:
Try with ./pharo or try with an absolute image path.
On Wed, Jun 27, 2018, 04:03 Tim Mackinnon <tim@testit.works> wrote:
Iâve not noticed that problem on ubuntu or AWS lambda so there must be something different going on.
Sent from my iPhone
On 27 Jun 2018, at 07:30, Otto Behrens <otto@finworks.biz> wrote:
Hi,
I just installed pharo 6.1 using the .zip file ( http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments.
The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image"
where
image = $*
The impact is that if I want to run a startup script, eg.
pharo my.image startup.st
pharo complains with "Could not open the Pharo image file: 'my.image startup.st'
So I must run the executable directly?
If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this?
Thanks Otto
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
I extracted the file that I downloaded again and checked. The file ( http://files.pharo.org/platform/Pharo6.1-64-linux.zip) seems to have an old VM zipped: /opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955 What I get with wget -O - https://get.pharo.org/64/61+vm | bash is: pharo-vm/lib/pharo/5.0-201805090836 On Wed, Jun 27, 2018 at 9:45 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
That's strange, is this a new problem or you always had it?
I've just tested it, pharo 61 64 bits.
$ wget -O - https://get.pharo.org/64/61+vm | bash [SNIP] $ ./pharo Pharo.image eval 1+1 2
Maybe the so called starter scripts (pharo, pharo-ui) are not the same using zeroconf and by downloading a plain vm like that?
On Wed, Jun 27, 2018 at 9:38 AM Otto Behrens <otto@finworks.biz> wrote:
I am running with an absolute image path.
The issue is definitely exec "$image" in the script. If I remove the "", i.e. exec $image, then it works.
/opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image startup.st"
gives me the same problem
On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri <serpi90@gmail.com> wrote:
Try with ./pharo or try with an absolute image path.
On Wed, Jun 27, 2018, 04:03 Tim Mackinnon <tim@testit.works> wrote:
Iâve not noticed that problem on ubuntu or AWS lambda so there must be something different going on.
Sent from my iPhone
On 27 Jun 2018, at 07:30, Otto Behrens <otto@finworks.biz> wrote:
Hi,
I just installed pharo 6.1 using the .zip file (http://files.pharo.org/ platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments.
The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image"
where
image = $*
The impact is that if I want to run a startup script, eg.
pharo my.image startup.st
pharo complains with "Could not open the Pharo image file: 'my.image startup.st'
So I must run the executable directly?
If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this?
Thanks Otto
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
Am 27.06.2018 um 09:38 schrieb Otto Behrens <otto@finworks.biz>:
I am running with an absolute image path.
The issue is definitely exec "$image" in the script. If I remove the "", i.e. exec $image, then it works.
/opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image startup.st <http://startup.st/>"
Does just giving a path still work. I use the commandline option vm pharo.image st path/to/script.st <http://script.st/> Norbert
gives me the same problem
On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri <serpi90@gmail.com <mailto:serpi90@gmail.com>> wrote: Try with ./pharo or try with an absolute image path.
On Wed, Jun 27, 2018, 04:03 Tim Mackinnon <tim@testit.works> wrote: Iâve not noticed that problem on ubuntu or AWS lambda so there must be something different going on.
Sent from my iPhone
On 27 Jun 2018, at 07:30, Otto Behrens <otto@finworks.biz <mailto:otto@finworks.biz>> wrote:
Hi,
I just installed pharo 6.1 using the .zip file (http://files.pharo.org/platform/Pharo6.1-64-linux.zip <http://files.pharo.org/platform/Pharo6.1-64-linux.zip>) and battled to start up pharo with arguments.
The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image"
where
image = $*
The impact is that if I want to run a startup script, eg.
pharo my.image startup.st <http://startup.st/>
pharo complains with "Could not open the Pharo image file: 'my.image startup.st <http://startup.st/>'
So I must run the executable directly?
If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this?
Thanks Otto
Thanks, but it does not. I give a full path for both the image and the startup files. It must have something to do with the stuff packaged in the zip file. On Wed, Jun 27, 2018 at 9:59 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.06.2018 um 09:38 schrieb Otto Behrens <otto@finworks.biz>:
I am running with an absolute image path.
The issue is definitely exec "$image" in the script. If I remove the "", i.e. exec $image, then it works.
/opt/pharo/pharo6.1-64/bin/lib/pharo/5.0-201708271955/pharo "my.image startup.st"
Does just giving a path still work. I use the commandline option
vm pharo.image *st* path/to/script.st
Norbert
gives me the same problem
On Wed, Jun 27, 2018 at 9:28 AM, Julián Maestri <serpi90@gmail.com> wrote:
Try with ./pharo or try with an absolute image path.
On Wed, Jun 27, 2018, 04:03 Tim Mackinnon <tim@testit.works> wrote:
Iâve not noticed that problem on ubuntu or AWS lambda so there must be something different going on.
Sent from my iPhone
On 27 Jun 2018, at 07:30, Otto Behrens <otto@finworks.biz> wrote:
Hi,
I just installed pharo 6.1 using the .zip file ( http://files.pharo.org/platform/Pharo6.1-64-linux.zip) and battled to start up pharo with arguments.
The issue is that the pharo bash script (in the extracted home dir) quotes all arguments:
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image"
where
image = $*
The impact is that if I want to run a startup script, eg.
pharo my.image startup.st
pharo complains with "Could not open the Pharo image file: 'my.image startup.st'
So I must run the executable directly?
If so, some questions about the options that the bash script passes in: --plugins "$LINUX" is this necessary? will the default not be enough? --encoding utf8 the usage output says for example --textenc default is "UTF-8". Is utf8 the same thing? -vm-display-X11 I tried starting without this, and it worked. Do I need to explicitly start with this?
Thanks Otto
On Wednesday 27 June 2018 01:08 PM, Otto Behrens wrote:
I am running with an absolute image path.
The issue is definitely exec "$image" in the script. If I remove the "", i.e. exec $image, then it works.
The double quotes are required here to skip splitting arguments with embedded spaces into different words. I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting. Also, the image_count should be checked before calling zenity. Can you try with this version? ```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then image="$RESOURCES"/*.image elif which zenity &>/dev/null; then image="$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file-filter '*')" else image="$RESOURCES/Pharo6.1-64.image" fi else image="$@" fi # execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$image" ```` HTH .. Subbu
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry! Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix : ```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi # execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ```` HTH .. Subbu
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082 Cheers, Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads. Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle. Itâs cool to see so many clever minds on this. Tim Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
Thanks for the effort guys. I tried to download the image, sources and vm separately (basically extracted what https://get.pharo.org/64/61+vm does), but ran into fresh trouble. Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in terms of security? It should be quite possible to inject a lovely trojan horse with this, or not? Secondly, the pharo bash script that it generates is different to the one in the zip. The directory structure (where the image & vm goes) is also different. Why is that? I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got the following, which I tried to do, but that did not take the message away: pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below: cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END and report to the pharo mailing list whether this improves behaviour. You will need to log out and log back in for the limits to take effect. (I did do this). I reverted to the deb package for now, because this have take some time and I can't focus on it now. I'll give it another shot soon, I hope On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote:
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads.
Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle.
Itâs cool to see so many clever minds on this.
Tim
Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
2018-06-27 23:21 GMT-03:00 Otto Behrens <otto@finworks.biz>:
Thanks for the effort guys.
I tried to download the image, sources and vm separately (basically extracted what https://get.pharo.org/64/61+vm does), but ran into fresh trouble.
Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in terms of security? It should be quite possible to inject a lovely trojan horse with this, or not?
Yes, this is possible: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
Secondly, the pharo bash script that it generates is different to the one in the zip. The directory structure (where the image & vm goes) is also different. Why is that?
I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got the following, which I tried to do, but that did not take the message away:
pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:
cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END
and report to the pharo mailing list whether this improves behaviour.
You will need to log out and log back in for the limits to take effect.
(I did do this).
I reverted to the deb package for now, because this have take some time and I can't focus on it now.
I'll give it another shot soon, I hope
On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote:
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads.
Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle.
Itâs cool to see so many clever minds on this.
Tim
Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand <hernan.morales@gmail.com>:
2018-06-27 23:21 GMT-03:00 Otto Behrens <otto@finworks.biz>:
Thanks for the effort guys.
I tried to download the image, sources and vm separately (basically extracted what https://get.pharo.org/64/61+vm does), but ran into fresh trouble.
Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in terms of security? It should be quite possible to inject a lovely trojan horse with this, or not?
Yes, this is possible:
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
I like this kind of articles because it proofs every time how less people know about security. If it comes to security eyerone goes hysterical. The basic assumption in it is that you need back pressure in order to detect it. But as the get.pharo.org script is not big enough.... the whole thing is not possible. Finished. Next. But what is really funny is that there is something not mentioned. Because for this to work you need to have control over the server meaning get.pharo.org. If this is the case I can also make the client download a different image with malicious code or a vm or .. Or even better. Every piece of software you download has the same problem. Just because it comes with an installer doesnât mean it is safe. Security problem scenarios are often theoretical problems. The need to be checked against real conditions in order to identify a threat or not. Norbert
Secondly, the pharo bash script that it generates is different to the one in the zip. The directory structure (where the image & vm goes) is also different. Why is that?
I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got the following, which I tried to do, but that did not take the message away:
pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:
cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END
and report to the pharo mailing list whether this improves behaviour.
You will need to log out and log back in for the limits to take effect.
(I did do this).
I reverted to the deb package for now, because this have take some time and I can't focus on it now.
I'll give it another shot soon, I hope
On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote:
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads.
Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle.
Itâs cool to see so many clever minds on this.
Tim
Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
On 17 Jul 2018, at 09:07, Norbert Hartl <norbert@hartl.name> wrote:
Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand <hernan.morales@gmail.com>:
2018-06-27 23:21 GMT-03:00 Otto Behrens <otto@finworks.biz>:
Thanks for the effort guys.
I tried to download the image, sources and vm separately (basically extracted what https://get.pharo.org/64/61+vm does), but ran into fresh trouble.
Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in terms of security? It should be quite possible to inject a lovely trojan horse with this, or not?
Yes, this is possible:
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
I like this kind of articles because it proofs every time how less people know about security. If it comes to security eyerone goes hysterical. The basic assumption in it is that you need back pressure in order to detect it. But as the get.pharo.org <http://get.pharo.org/> script is not big enough.... the whole thing is not possible. Finished. Next.
But what is really funny is that there is something not mentioned. Because for this to work you need to have control over the server meaning get.pharo.org <http://get.pharo.org/>. If this is the case I can also make the client download a different image with malicious code or a vm or .. Or even better. Every piece of software you download has the same problem. Just because it comes with an installer doesnât mean it is safe.
Security problem scenarios are often theoretical problems. The need to be checked against real conditions in order to identify a threat or not.
+1 Esteban
Norbert
Secondly, the pharo bash script that it generates is different to the one in the zip. The directory structure (where the image & vm goes) is also different. Why is that?
I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got the following, which I tried to do, but that did not take the message away:
pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:
cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END
and report to the pharo mailing list whether this improves behaviour.
You will need to log out and log back in for the limits to take effect.
(I did do this).
I reverted to the deb package for now, because this have take some time and I can't focus on it now.
I'll give it another shot soon, I hope
On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote:
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads.
Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle.
Itâs cool to see so many clever minds on this.
Tim
Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
2018-07-17 4:07 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand <hernan.morales@gmail.com>:
2018-06-27 23:21 GMT-03:00 Otto Behrens <otto@finworks.biz>:
Thanks for the effort guys.
I tried to download the image, sources and vm separately (basically extracted what https://get.pharo.org/64/61+vm does), but ran into fresh trouble.
Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in terms of security? It should be quite possible to inject a lovely trojan horse with this, or not?
Yes, this is possible:
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
I like this kind of articles because it proofs every time how less people know about security. If it comes to security eyerone goes hysterical. The basic assumption in it is that you need back pressure in order to detect it. But as the get.pharo.org script is not big enough.... the whole thing is not possible. Finished. Next.
Well, you have a case: "People telling people to execute arbitrary code over the network" : https://curlpipesh.tumblr.com/ ;) When it comes to security, it is better to keep humble. Even the guys behind cryptographic functions got caught, so it is better to follow the best practices around, at least in a really complex domain as security. You don't need a big script to get fooled, have a look at http://people.zoy.org/~sam/filsdepute.txt and copy-paste its contents in a text editor.
But what is really funny is that there is something not mentioned. Because for this to work you need to have control over the server meaning get.pharo.org. If this is the case I can also make the client download a different image with malicious code or a vm or .. Or even better. Every piece of software you download has the same problem. Just because it comes with an installer doesnât mean it is safe.
Security problem scenarios are often theoretical problems. The need to be checked against real conditions in order to identify a threat or not.
We don't agree this time Norbert. Even without a real scenario the theoretical problem is enough. Two examples are: 1) In security if a vector is prone to attacks, with a success probability, then could be considered obsolete or weak, and weakness increases over time (SHA-1, SHA-2). As computer speeds gets faster, they just calculate an algorithm resistance and estimate its life-expectancy. 2) People use package managers precisely because is a delivery mechanism which transfer the burden of trust from the Pharo maintainers to the package manager (which verify signatures). That without counting the pleasure of deniability if an installation got compromised :) Cheers Hernán
Norbert
Secondly, the pharo bash script that it generates is different to the one in the zip. The directory structure (where the image & vm goes) is also different. Why is that?
I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got the following, which I tried to do, but that did not take the message away:
pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:
cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END
and report to the pharo mailing list whether this improves behaviour.
You will need to log out and log back in for the limits to take effect.
(I did do this).
I reverted to the deb package for now, because this have take some time and I can't focus on it now.
I'll give it another shot soon, I hope
On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote:
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads.
Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle.
Itâs cool to see so many clever minds on this.
Tim
Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
Am 17.07.2018 um 17:31 schrieb Hernán Morales Durand <hernan.morales@gmail.com>:
2018-07-17 4:07 GMT-03:00 Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand <hernan.morales@gmail.com>:
2018-06-27 23:21 GMT-03:00 Otto Behrens <otto@finworks.biz>:
Thanks for the effort guys.
I tried to download the image, sources and vm separately (basically extracted what https://get.pharo.org/64/61+vm does), but ran into fresh trouble.
Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in terms of security? It should be quite possible to inject a lovely trojan horse with this, or not?
Yes, this is possible:
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
I like this kind of articles because it proofs every time how less people know about security. If it comes to security eyerone goes hysterical. The basic assumption in it is that you need back pressure in order to detect it. But as the get.pharo.org script is not big enough.... the whole thing is not possible. Finished. Next.
Well, you have a case: "People telling people to execute arbitrary code over the network" : https://curlpipesh.tumblr.com/ <https://curlpipesh.tumblr.com/> ;)
When it comes to security, it is better to keep humble. Even the guys behind cryptographic functions got caught, so it is better to follow the best practices around, at least in a really complex domain as security. You don't need a big script to get fooled, have a look at http://people.zoy.org/~sam/filsdepute.txt <http://people.zoy.org/~sam/filsdepute.txt> and copy-paste its contents in a text editor.
But what is really funny is that there is something not mentioned. Because for this to work you need to have control over the server meaning get.pharo.org <http://get.pharo.org/>. If this is the case I can also make the client download a different image with malicious code or a vm or .. Or even better. Every piece of software you download has the same problem. Just because it comes with an installer doesnât mean it is safe.
Security problem scenarios are often theoretical problems. The need to be checked against real conditions in order to identify a threat or not.
We don't agree this time Norbert. Even without a real scenario the theoretical problem is enough. Two examples are: 1) In security if a vector is prone to attacks, with a success probability, then could be considered obsolete or weak, and weakness increases over time (SHA-1, SHA-2). As computer speeds gets faster, they just calculate an algorithm resistance and estimate its life-expectancy. 2) People use package managers precisely because is a delivery mechanism which transfer the burden of trust from the Pharo maintainers to the package manager (which verify signatures). That without counting the pleasure of deniability if an installation got compromised :)
Iâm not sure why we disagree here. I said that all of those scenarios need to be checked against real conditions. An algorithm that can brute forced due to the increase in computing power is a real condition. What I was saying is that not every theoretical problem is one you need to take care about. Why I am saying this? In my career I met far too many âexpertsâ dealing every theoretical problem as a real one without understanding the impact. Those people often sit at important positions in corporate infrastructure restricting the usage of the internet and software to a bare minimum. And they cannot see that they produce an economical damage to the company while keeping everyone from working. In order to justify that the damage it should at least be a real threat, donât you think? The cost of the measure you take to protect needs to correlate in a sensible manner to the value you want to protect. Norbert
Cheers
Hernán
Norbert
Secondly, the pharo bash script that it generates is different to the one in the zip. The directory structure (where the image & vm goes) is also different. Why is that?
I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got the following, which I tried to do, but that did not take the message away:
pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:
cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END
and report to the pharo mailing list whether this improves behaviour.
You will need to log out and log back in for the limits to take effect.
(I did do this).
I reverted to the deb package for now, because this have take some time and I can't focus on it now.
I'll give it another shot soon, I hope
On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote:
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads.
Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle.
Itâs cool to see so many clever minds on this.
Tim
Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
I am happy to see some real security conversation here. Ultimately, security is about risk management, so both of you are somewhat correct. However, on the whole I tend to agree with Hernán. OTOH, it is theoretically possible to break any known cipher or hash algorithm, given sufficient resources, time and motivation. One needs to understand the measure of risk and understand their own risk tolerance to decide whether or not something is a viable threat. Good security means good behavior as well as technical solutions. Questioning 'wget â¦. | bashâ absolutely counts as good behavior in my book. Jerry Kott This message has been digitally signed. PGP Fingerprint: A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5
On 17-07-2018, at 8:31 AM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-07-17 4:07 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
Am 17.07.2018 um 05:14 schrieb Hernán Morales Durand <hernan.morales@gmail.com>:
2018-06-27 23:21 GMT-03:00 Otto Behrens <otto@finworks.biz>:
Thanks for the effort guys.
I tried to download the image, sources and vm separately (basically extracted what https://get.pharo.org/64/61+vm does), but ran into fresh trouble.
Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in terms of security? It should be quite possible to inject a lovely trojan horse with this, or not?
Yes, this is possible:
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
I like this kind of articles because it proofs every time how less people know about security. If it comes to security eyerone goes hysterical. The basic assumption in it is that you need back pressure in order to detect it. But as the get.pharo.org script is not big enough.... the whole thing is not possible. Finished. Next.
Well, you have a case: "People telling people to execute arbitrary code over the network" : https://curlpipesh.tumblr.com/ ;)
When it comes to security, it is better to keep humble. Even the guys behind cryptographic functions got caught, so it is better to follow the best practices around, at least in a really complex domain as security. You don't need a big script to get fooled, have a look at http://people.zoy.org/~sam/filsdepute.txt and copy-paste its contents in a text editor.
But what is really funny is that there is something not mentioned. Because for this to work you need to have control over the server meaning get.pharo.org. If this is the case I can also make the client download a different image with malicious code or a vm or .. Or even better. Every piece of software you download has the same problem. Just because it comes with an installer doesnât mean it is safe.
Security problem scenarios are often theoretical problems. The need to be checked against real conditions in order to identify a threat or not.
We don't agree this time Norbert. Even without a real scenario the theoretical problem is enough. Two examples are: 1) In security if a vector is prone to attacks, with a success probability, then could be considered obsolete or weak, and weakness increases over time (SHA-1, SHA-2). As computer speeds gets faster, they just calculate an algorithm resistance and estimate its life-expectancy. 2) People use package managers precisely because is a delivery mechanism which transfer the burden of trust from the Pharo maintainers to the package manager (which verify signatures). That without counting the pleasure of deniability if an installation got compromised :)
Cheers
Hernán
Norbert
Secondly, the pharo bash script that it generates is different to the one in the zip. The directory structure (where the image & vm goes) is also different. Why is that?
I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got the following, which I tried to do, but that did not take the message away:
pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:
cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END
and report to the pharo mailing list whether this improves behaviour.
You will need to log out and log back in for the limits to take effect.
(I did do this).
I reverted to the deb package for now, because this have take some time and I can't focus on it now.
I'll give it another shot soon, I hope
On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote:
When we get confirmation of success - we need to make sure this gets applied to both zeroconf and official downloads.
Anything we can do to simplify and make it robust is gratefully appreciated as there is nothing worse than falling at the lunch hurdle.
Itâs cool to see so many clever minds on this.
Tim
Sent from my iPhone
On 27 Jun 2018, at 19:52, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu.ml@gmail.com>:
On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote:
The double quotes are required here to skip splitting arguments with embedded spaces into different words.
I suspect the error is earlier in the image=$@ assignment. This requires double quotes. Double quotes are also required while calling zenity to avoid word splitting.
My earlier fix is also in error, Sorry!
Essentially, we are mixing up single value variable (image) with argument array ($@). I found a cleaner fix :
```` if [ $# -eq 0 ]; then image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` if [ "$image_count" -eq 1 ]; then set -- "$RESOURCES"/*.image elif which zenity &>/dev/null; then set -- "$(zenity --title 'Select an image' --file-selection --filename "$RESOURCES/" --file-filter '*.image' --file- filter '*')" else set -- "$RESOURCES/Pharo6.1-64.image" fi fi
Use $() instead of backticks for command substitution: http://mywiki.wooledge.org/BashFAQ/082
Cheers,
Hernán
# execute exec "$LINUX/pharo" \ --plugins "$LINUX" \ --encoding utf8 \ -vm-display-X11 \ "$@" ````
HTH .. Subbu
participants (9)
-
Esteban Lorenzano -
Guillermo Polito -
Hernán Morales Durand -
Jerry Kott -
Julián Maestri -
K K Subbu -
Norbert Hartl -
Otto Behrens -
Tim Mackinnon