Open ghost opened 7 years ago
There should be some output in the console. Something like spawn ...
when you try to run anything using script runner, can you tell me what it says?
Hello.
In direct answer to your question: spawn -l
.
This time I asked the system to open a terminal: Script Runner : Shell
.
The shell opens and has a cursor flashing inside. It is here that I expect Powershell or Command Prompt to open, when comparing to how other terminal packages worked for me before on my Windows 7 system.
An error in the console - as mentioned before. Detail now follows
The answer is spawn -l
followed by the object detail:
spawn -l Array[0]
length : 0
__proto__ : Array[0]
concat : concat()
constructor : Array()
copyWithin : copyWithin()
entries : entries()
every : every()
fill : fill()
filter : filter()
find : find()
findIndex : findIndex()
forEach : forEach()
includes : includes()
indexOf : indexOf()
join : join()
keys : keys()
lastIndexOf : lastIndexOf()
length : 0
map : map()
pop : pop()
push : push()
reduce : reduce()
reduceRight : reduceRight()
reverse : reverse()
shift : shift()
slice : slice()
some : some()
sort : sort()
splice : splice()
toLocaleString : toLocaleString()
toString : toString()
unshift : unshift()
Symbol(Symbol.iterator) : values()
Symbol(Symbol.unscopables) : Object
__proto__ : Object
This is followed by a print-out of the environmentals as an object starting with:
Object
ALLUSERSPROFILE : "C:\ProgramData"
APPDATA : "C:\Users\Dan\AppData\Roaming"
ATOM_HOME : "C:\Users\Dan\.atom"
....
Thereafter the actual message as stated before:
Uncaught (in promise) Error: File not found:
...
The link provided with the above mentioned system error:
C:\Users\Dan\.atom\packages\script-runner\node_modules\node-pty\lib\windowsPtyAgent.js
The link pages to code:
ar WindowsPtyAgent = (function () {
function WindowsPtyAgent(file, args, env, cwd, cols, rows, debug) {
var _this = this;
// Sanitize input variable.
cwd = path.resolve(cwd);
// Compose command line
var commandLine = argsToCommandLine(file, args);
// Open pty session.
// ..................VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV MARKED
var term = pty.startProcess(file, commandLine, env, cwd, cols, rows, debug);
// ..................^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MARKED
// Terminal pid.
this._pid = term.pid;
this._innerPid = term.innerPid;
this._innerPidHandle = term.innerPidHandle;
// Not available on windows.
this._fd = term.fd;
// Generated incremental number that has no real purpose besides using it
// as a terminal id.
this._pty = term.pty;
...
...
Next instructions?
Same computer, same installation now reports also -
Deprecation Warning: Argument to 'path.dirname' must be a string
Object.dirname - C:\Users\Dan\AppData\Local\atom\app-1.19.0\resources\app\src\electron-shims.js:9:10
Object.runShell - C:\Users\Dan\.atom\packages\script-runner\lib\script-runner.js:79:19
HTMLElement.scriptRunnerShell - C:\Users\Dan\.atom\packages\script-runner\lib\script-runner.js:62:18
CommandRegistry.handleCommandEvent - <embedded>:21847:35
<unknown> - <embedded>:21585:65
Object.didConfirmSelection - <embedded>:42530:35
Windows7 SP1, Avast Free Antivirus V17.5, Atom V1.19.0, Script Runner V2.2.1.
What would make the most sense for a shell on windows? powershell.exe
?
Can you tell me if on windows for you, the following script works?
#!python.exe
print "Hello World"
Hello.
[1].
As a feature it might be good to have a user configuration where one can
set which shell to trigger. Please have a look at what the other guys are
doing - see my community post for two of those packages. It is best to
trigger the full path. On a standard Windows system you could have
C:\Windows\System32\cmd.exe
and
C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
. These work
out-of-the-box.
Microsoft has also released a later version of Powershell
that is now
open for the public. Not sure if it is fully open code. LINK
Another shell I have used is Cmder
. That one is a bit more tricky to get
running. LINK
[2]
Yes that script works. But in Windows it is different than what you know.
The extension of the file - py
- is associated with the action. I have
not much control in just opening a normal text file and pushing it to
execute. We also do not need the BANG line. However - if I had typed in
python.exe helloWorld.py
, the correct files would have executed. In my
case I have python
is linked to python 2. Let me add.. the script should
be already in the work directory. Using the BANG line to be the way to
execute the code is a brilliant idea.
Variations would be to (a) call the full path of the python
command and
then (b) call the full path of the script file. Because the user determine
the BANG line, (a) is not that big a worry - he should make sure it is
correct. In my case (custom configured) I can invoke by saying any:
#!python.exe
#!c:/python27/python.exe
#!python
#!python2
#!py2
#!c:/python36/python.exe
#!python3
#!py3
Also my favourite enhancement:
#!python3 -i
I understand the mechanisms that script
uses to "run" a script - the
look-up table and identifying which language / grammar is used in the code.
More - highlighting code and triggering execution for script
: a dummy
file is created and the dummy file is executed. Then the code is not pushed
directly to the command and terminal. This solution I think Windows would
require.
The other terminals also offer very much. The "platformio" version has
custom text that the user can configure. This can be pushed to the
terminal. It was possible for me to enhance this ability to trigger the
active file to execute (example: python -i helloWorld.py
) when
identifying what grammar it is and extracting the full path. Even
drag-and-drop from the tree to the open terminal I could hi-jack.
These are a big mouth full. My suggestion would be to look first into the error and [1] - if you are open for it.
I am willing to exchange ideas if you would want to.Warning - I only starting looking into the world of Atom a month ago.. in my spare time.
Regards.
Interpreting the bang line is done entirely within script-runner for the purpose of determining the interpreter to use. Because of how it's implemented, it also works on Windows. Are you in agreement that this is the best approach or do you think there is a better alternative?
It is a design choice. There is no right or wrong in that. How script
does it is nice for the lazy guy - identifying the grammar and then extracting and executing solution from a fixed list.
Your solution is flexible - the user decides what is used on how it is called. Code that requires compilation first will be a problem as there is a two step process.
We have to debate this some more to highlight the pros and cons. For the short and perhaps the medium term, the main stream can stay as it is.
My vision is to see a combo terminal-shell-execution combining script
, script-runner and
platformio-ide-terminal. I wish I could get you guys (and all the forks of
terminal2` ) to work together on such an effort - kicking VSCode's ***! We could achieve much more if we could work together.
This is your project. It is your vision. Your rules. Yet I am willing to make my opinion known.. regardless if you want to go that direction or not. PM me at the community page if you want.
Focussing in the here and now - Leave your concept in place. Do you have an idea on getting your package to function on my machine? (a friendly request)
- Dan
It is a design choice. There is no right or wrong in that. How script does it is nice for the lazy guy - identifying the grammar and then extracting and executing solution from a fixed list.
Agreed. script-runner
does support this automatic detection, but it's hard to select the right interpreter in a general fashion, while also supporting windows and unix.
To elaborate - if you type the following:
puts "Hello World"
and set the language to Ruby
, then run the script (even without saving) script-runner
will invoke ruby
.
Your solution is flexible - the user decides what is used on how it is called. Code that requires compilation first will be a problem as there is a two step process.
Yes, hash bang style provides per-script flexibility.
We have to debate this some more to highlight the pros and cons. For the short and perhaps the medium term, the main stream can stay as it is.
I think that supporting both methods is good, but the automatic detection/selection of interpreter should not be the responsibility of script-runner but ideally "Tell me how to run Ruby on your platform" should be handled by the OS.
My vision is to see a combo terminal-shell-execution combining script, script-runner andplatformio-ide-terminal. I wish I could get you guys (and all the forks ofterminal2` ) to work together on such an effort - kicking VSCode's ***! We could achieve much more if we could work together.
I agree to a certain extent. There are some things script-runner
was designed to do better though:
script
or atom-runner
do this yet)Focussing in the here and now - Leave your concept in place. Do you have an idea on getting your package to function on my machine? (a friendly request)
Can you clarify this in more detail? What's currently not working?
Can you clarify this in more detail? What's currently not working?
?
!?
Please read this report topic from the start. Atom under Windows7 reports an error in the console when I try to use your Package. This is the core reason of this topic.
The pane opens - only frame + button and no terminal, when the Package is triggered. This is detailed above - there has been no change in this.
I did not answer your earlier question correctly [blush] I have diverted this topic in a bad way - VERY SORRY.
#!python.exe
print "Hello World"
The above code runs when I execute the code OUTSIDE of Atom.. say for example in IDLE or when calling the file in the system prompt.
The result when called INSIDE Atom as per `script-runner` ->
Console messages:
spawn python.exe Array[1] ... Uncaught (in promise) Error: Error launching WinPTY agent: ConnectNamedPipe failed: Windows error 232 ...
The shell is empty - no terminal, only a flashing cursor.
I have sent an email with a picture to you. Github is not allowing me to add it here (?).
Hello.
First my thanks for the owner of this package for getting his package installed on my system. This resolved also issues for me on other terminal packages. LINK WINDOWS 7 SP1, Language = English ATOM V1.19.................... install 1 ATOM V1.20 BETA 2 ... install 2 as portable Python V2.7 as primary Python V3.6 as secondary The symptoms are the same for both installations. There are two caught errors: 1. Running a script:
2. Disabling the package from SETTINGS:
At first there was a problem with installing the package. This was detailed and resolved in the community forum posting. This may or may not still have influence on this case.
Now the package does install. The terminal does open when envoking the run command from the command pallet. I have used
...\.atom\packages\script-runner\examples\test.py
for the test. I can confirm that the command in the Windows prompt ofpython test.py
does work as expected.What other information would be helpful to you? - Dan Padric