Changing my code to use DefineEncodings instead of ConvertEncodings works as expected on reading the file, but not from getting the output of the shelled command directly:
[code] Dim theShell As New Shell
theShell.Mode = 2
theShell.Execute “ls -la /Users/tjones > /tmp/test.txt”
Do
App.DoEvents(5) // leave it alone - it’s a test…
Loop Until Not theShell.IsRunning
Dim tis As TextInputStream
Dim f As FolderItem = GetFolderItem("/tmp/test.txt", FolderItem.PathTypeShell)
tis = TextInputStream.Open(f)
TextArea1.SelText = DefineEncoding(tis.ReadAll, Encodings.UTF8)
tis.close[/code]
Results are correct.
-rw-r--r-- 1 tjones staff 878 May 30 14:27 execbru.class
-rw-r--r-- 1 tjones staff 399 May 30 14:27 execbru.java
drwxr-xr-x 3 tjones staff 102 May 29 14:07 isus
drwxr-xr-x 2 tjones staff 68 Jun 20 15:41 la Cte d'Ivoire
drwxr-xr-x 2 tjones staff 68 Jun 20 15:41 la Rpublique centrafricaine
-rw-r--r-- 1 tjones staff 494 May 16 10:19 test
So, this is still a bug that the shell is not returning proper data in Mode 2.
That’s because shell.result has already lost the encoding information and replaced the significant bytes by question marks. But unless one does a very, very long ls, the temporary file is an elegant workaround. BinaryStream or TextInputStream
As to what shell, It’s not like we have a choice in the resulting project when calling Shell.Execute - there was a Feedback Request filed back in 2009 asking for a way to define the backend (bash, csh, python, etc.), but it’s long since been closed.
The Async shell is used where you need to talk to the backend process.
The point here is that when you use the original code in Mode = 0 or Mode = 1, you get back the properly encoded string. It’s when you change that same code to use Mode = 2 that things get sideways and the result is question marks instead of the expected content. That is a bug.
Right, but you normally wouldn’t use it that way. The example is a little askew. As for selecting your shell, you certainly can do that as part of your command line. And you would definitely want to do that in interactive mode (Mode 2).
I am willing to step back, but not to fall back down the cliff. Using sh, csh or bash will require yet a series of experimentations and I am satisfied to have provided the OP with a working solution.
Now, why he wants to use mode 2 he did not explain, nor did he post his code.
I know from past experiments that Mode 1 can very nicely hang the application if the shell does not end.
With this
s1.execute( "cd /Users/Mitch/Desktop ; sh ; ls -al" )
All I get is sh-3.2$. Nice prompt but that’s not what I want. How would you write the command line ?
[quote=103745:@Tim Jones]As to what shell, It’s not like we have a choice in the resulting project when calling Shell.Execute - there was a Feedback Request filed back in 2009 asking for a way to define the backend (bash, csh, python, etc.), but it’s long since been closed.
[/quote]
You mean http://documentation.xojo.com/index.php/Shell.Backend ?
Granted, for just pulling a listing form an ‘;s’, I’d use mode 1. However,in the real world I use it that way all the time. When I need to do a multi-step process that is all linear and requires responses, I use a mode 2 shell instantiated in the method.
Yes - just exactly like that. When did THAT get implemented and why haven’t I found out about it before now ?
[quote=103767:@Tim Jones]
Yes - just exactly like that. When did THAT get implemented and why haven’t I found out about it before now ?[/quote]
Docs for it go back to 2010
Its present in 2010r3 and r4
So “quite some time ago”
Dim theShell As New Shell
theShell.Mode = 2
theShell.Execute "sh"
theShell.WriteLine "ls -la /Users/tjones"
theShell.WriteLine "exit"
Do
App.DoEvents(5)
Loop Until Not theShell.IsRunning
TextArea1.SelText = DefineEncoding(theShell.ReadAll, Encodings.UTF8)
Still doesn’t fix the returned encoding problem, though.
There’s nothing there TO define the encoding of
I have one dir with a dir in it named E?
When I get the data from shell.readall those are already 45 65 3F 3F 69 3F or Ee??i??
And this is true of EVERY shell I can find to use on OS X (sh, bash csh, zsh ksh you name it)
Defining the encoding isn’t going to alter the fact that those chars are already gone before I ever see them and replaced with ascii question marks
[quote=103789:@Norman Palardy]There’s nothing there TO define the encoding of
I have one dir with a dir in it named Eë?
When I get the data from shell.readall those are already 45 65 3F 3F 69 3F or Ee??i??
And this is true of EVERY shell I can find to use on OS X (sh, bash csh, zsh ksh you name it)
Defining the encoding isn’t going to alter the fact that those chars are already gone before I ever see them and replaced with ascii question marks[/quote]
Unless you change your Shell mode to 0 or 1. In that case, you get back the proper encoded text in Shell.ReadAll. Unless the mode changes the shell used, there is a bug.
Again, the bug is in the difference between using a shell in mode 0 or 1 versus mode 2.
I’ll have to double check with the other engineers but since interactive mode (2) is mostly expected to be a “terminal” things are set up that way and that implies a certain amount of character processing (not by us though).
The other modes are basically getting raw bytes completely unprocessed.
[quote=103908:@Norman Palardy]I’ll have to double check with the other engineers but since interactive mode (2) is mostly expected to be a “terminal” things are set up that way and that implies a certain amount of character processing (not by us though).
The other modes are basically getting raw bytes completely unprocessed.[/quote]
Would it not be possible to add a “raw” backend where characters are not processed, akin to what happens in modes 0 and 1 ? That would solve the issue.
Besides, why is the “terminal” behavior different from Mac OS X Terminal and Windows Command Prompt, where accented characters are correctly displayed ? At the very least, if actually mode 2 is supposed to emulate the system terminal, it should do it the same way.
I am not a fanatic of localization, and can live with an Anglo-Saxon low ASCII GUI. But in this case, the wrong rendition of accented characters is a real nuisance for all non-English speaking users which can render the shell unusable in certain applications. I am glad to provide a workaround, but still, I think it is a bug worth correcting.
[quote=103982:@Michel Bujardet]Would it not be possible to add a “raw” backend where characters are not processed, akin to what happens in modes 0 and 1 ? That would solve the issue.
[/quote]
It might
We had a quick peek at that this morning but no conclusions were reached.
Other priorities to look after and all that
Shell ISN’T Terminal but people generally expect that it is. It’s not.
We’d actually have to do something different to make it BE Terminal on OS X and Linux & the command prompt on Windows.
Then whatever you typed in to terminal would just work.
But it would not be a “Shell” - it would be a Terminal which implies many more things like what kind of tty, etc
?[/quote]