Command Shell in Pharo 4
So I decided to give Command Shell a spin using today's Pharo 4 release and I have some issues *a) The text is too small* . After some investigation I found that the size is defined in ShellWindowMorph class>>textStyle textStyle "A fixed width font for the text morph" ^ (TextStyle named: 'DefaultFixedTextStyle') ifNil: [TextStyle default] I assume there is a reason why a fixed size font is used . I changed it to just TextStyle default and works fine. *b) no ~ folder.* Trying a "cd ~" command does not work it complains that the folder does not exist. *c) not able to run shell scripts or other scripts* (eg. python scripts). For example if I try "./blender.sh" even though this command works fine in my macos terminal and iTerm2 , it does not work in Command Shell and complains that it cannot find the command.
also I tried this $ bash blender.sh Opening Blender ... blender.sh: line 2: cd: /Users/kilon/Library/Application Support/Pharo/images/Ephestos 28-10-2014/blender-build/build_darwin/bin/blender.app/Contents/macos: No such file or directory The file /Users/kilon/blender does not exist. Closed Blender. so it seems that even using the bash command does not work because it appends the path of the pharo image instead of the path of the current directory as it should. Because if I do $ pwd /Users/kilon which is the correct path that I always execute my script from. On Tue, Oct 28, 2014 at 11:09 AM, kilon alios <kilon.alios@gmail.com> wrote:
So I decided to give Command Shell a spin using today's Pharo 4 release and I have some issues
*a) The text is too small* . After some investigation I found that the size is defined in ShellWindowMorph class>>textStyle
textStyle "A fixed width font for the text morph"
^ (TextStyle named: 'DefaultFixedTextStyle') ifNil: [TextStyle default]
I assume there is a reason why a fixed size font is used . I changed it to just TextStyle default and works fine.
*b) no ~ folder.* Trying a "cd ~" command does not work it complains that the folder does not exist.
*c) not able to run shell scripts or other scripts* (eg. python scripts). For example if I try "./blender.sh" even though this command works fine in my macos terminal and iTerm2 , it does not work in Command Shell and complains that it cannot find the command.
On Tue, Oct 28, 2014 at 11:09:24AM +0200, kilon alios wrote:
So I decided to give Command Shell a spin using today's Pharo 4 release and I have some issues
*a) The text is too small* . After some investigation I found that the size is defined in ShellWindowMorph class>>textStyle
textStyle "A fixed width font for the text morph"
^ (TextStyle named: 'DefaultFixedTextStyle') ifNil: [TextStyle default]
I assume there is a reason why a fixed size font is used . I changed it to just TextStyle default and works fine.
The intent is to provide a readable fixed font for a "text terminal" window. It does not seem to work on Pharo. TextStyle named: 'DefaultFixedTextStyle' does not look like a fixed font to me, and as you say it is too small to be readable. I'm not too familiar with the font handling in Pharo, so if you can suggest a font that works better, that would be great.
*b) no ~ folder.* Trying a "cd ~" command does not work it complains that the folder does not exist.
CommandShell is a partial simulation of a unix shell. Many features of a real shell are not implemented. In this case, the $~ character is not being interpreted as it would be in a real shell, instead it is simply treated as a text character, so it does nothing at all.
*c) not able to run shell scripts or other scripts* (eg. python scripts). For example if I try "./blender.sh" even though this command works fine in my macos terminal and iTerm2 , it does not work in Command Shell and complains that it cannot find the command.
It may be that default directory conventions are different either on Pharo (compared to Squeak) or on OS X (compared to generic unix). I don't have a Mac so I'm afraid that I am guessing at this. FYI, CommandShell is keeping track of its own notion of the "current working directory". If you do a 'pwd' command in your command shell, it should show you what the command shell thinks is its current working directory. This also works in Widows by the way, which was something of a challenge handling those "drive letters" ;-) HTH, Dave
Why not use default as I did ? why the font needs to be fixed ? I am sorry I am not familiar with fonts in pharo so much, I did not even know what bitmap font is before I joined Pharo. For me it makes more sense to use the default because then it will use what the user have chosen in pharo settings. I dont know if you noticed my reply but I did use pwd and did try to run the script with the bash command. it looks like that pwd is not in sync with what Command Shell thinks as its current working directory , actually my bash file complained that the tool tried to run the script from the path of the actual pharo image which should not be the case . By the way congratulation on your tool, I see you have put a lot of effort in it and I am impressed by the amount of code and how well its organised. I will definetly keep exploring the code and further improve it if I can :) On Tue, Oct 28, 2014 at 1:55 PM, David T. Lewis <lewis@mail.msen.com> wrote:
On Tue, Oct 28, 2014 at 11:09:24AM +0200, kilon alios wrote:
So I decided to give Command Shell a spin using today's Pharo 4 release and I have some issues
*a) The text is too small* . After some investigation I found that the size is defined in ShellWindowMorph class>>textStyle
textStyle "A fixed width font for the text morph"
^ (TextStyle named: 'DefaultFixedTextStyle') ifNil: [TextStyle default]
I assume there is a reason why a fixed size font is used . I changed it to just TextStyle default and works fine.
The intent is to provide a readable fixed font for a "text terminal" window. It does not seem to work on Pharo. TextStyle named: 'DefaultFixedTextStyle' does not look like a fixed font to me, and as you say it is too small to be readable.
I'm not too familiar with the font handling in Pharo, so if you can suggest a font that works better, that would be great.
*b) no ~ folder.* Trying a "cd ~" command does not work it complains that the folder does not exist.
CommandShell is a partial simulation of a unix shell. Many features of a real shell are not implemented. In this case, the $~ character is not being interpreted as it would be in a real shell, instead it is simply treated as a text character, so it does nothing at all.
*c) not able to run shell scripts or other scripts* (eg. python scripts). For example if I try "./blender.sh" even though this command works fine
in
my macos terminal and iTerm2 , it does not work in Command Shell and complains that it cannot find the command.
It may be that default directory conventions are different either on Pharo (compared to Squeak) or on OS X (compared to generic unix). I don't have a Mac so I'm afraid that I am guessing at this.
FYI, CommandShell is keeping track of its own notion of the "current working directory". If you do a 'pwd' command in your command shell, it should show you what the command shell thinks is its current working directory. This also works in Widows by the way, which was something of a challenge handling those "drive letters" ;-)
HTH, Dave
Hi Kilon, On Tue, Oct 28, 2014 at 02:12:12PM +0200, kilon alios wrote:
Why not use default as I did ? why the font needs to be fixed ? I am sorry I am not familiar with fonts in pharo so much, I did not even know what bitmap font is before I joined Pharo. For me it makes more sense to use the default because then it will use what the user have chosen in pharo settings.
I am not sure that I am reading your question correctly, but the reason for selecting a fixed font rather than a proportional font is that it provides a nice display output for many of the unix command line tools. Back in the day, a terminal was a device with fixed width character displays, and programs that write to the display would often format the output data so that it would print nicely on a display or printer with fixed width character cells. The CommandShell window is a simple emulation of devices like this. It tries to use a fixed width font so that a unix utility command will display output in the expected character positions. In Squeak, TextStyle named: 'DefaultFixedTextStyle' answers a reasonable looking fixed width font, so that's what I use as the default. If no reasonable fixed font was available, I fell back on TextStyle default. The Pharo image that I am looking at now seems to answer a proportional font as its DefaultFixedTextStyle, so maybe there is something that needs to be fixed there. By the way, if you enter this in your CommandShell window, you will find that it is evaluated as a Smalltalk expression rather than as a unix shell command: $ TextStyle named: 'DefaultFixedTextStyle' a TextStyle Bitmap DejaVu Sans 7 $ That's one of the things I was trying to do with CommandShell, mix up Smalltalk expression evaluation with unix commands, and be able to mix them up in unix command pipelines like this: $ { #one. #two . #three . Smalltalk . true } ! | cat {#one. #two. #three. Smalltalk. true} $
I dont know if you noticed my reply but I did use pwd and did try to run the script with the bash command. it looks like that pwd is not in sync with what Command Shell thinks as its current working directory , actually my bash file complained that the tool tried to run the script from the path of the actual pharo image which should not be the case .
IIRC, there have been some changes made in Pharo versus Squeak that affect default working directories, possibly the image directory as opposed to the VM directory. I don't recall the details, but you may be seeing some issue related to that. CommandShell tries to start with some initial working directory, but it keeps track of its own current working directory after it has started. This works very differently on Unix and Windows, so it was necessary to keep track of it independent of what the image and/or VM were using as defaults. It may be that changes in Pharo have affected this, or maybe you are seeing issues related to OS X, I'm not sure.
By the way congratulation on your tool, I see you have put a lot of effort in it and I am impressed by the amount of code and how well its organised. I will definetly keep exploring the code and further improve it if I can :)
Thanks! It was sort of a hobby experiment, so don't expect it to be a professional grade replacement for /bin/bash ;-) Dave
participants (2)
-
David T. Lewis -
kilon alios