-
-
Notifications
You must be signed in to change notification settings - Fork 23
REPORTING> "Uncaught (in promise) Error: File not found" #81
Comments
There should be some output in the console. Something like |
Hello. In direct answer to your question: This time I asked the system to open a terminal: An error in the console - as mentioned before. Detail now follows The answer is
This is followed by a print-out of the environmentals as an object starting with:
Thereafter the actual message as stated before:
The link provided with the above mentioned system error:
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 -
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? |
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](
https://github.com/PowerShell/PowerShell)
Another shell I have used is `Cmder`. That one is a bit more tricky to get
running. [LINK](http://thebar.cc/atom-editor-cmder/)
|
[2] Variations would be to (a) call the full path of the
Also my favourite enhancement:
I understand the mechanisms that More - highlighting code and triggering execution for The other terminals also offer very much. The "platformio" version has These are a big mouth full. My suggestion would be to look first into the I am willing to exchange ideas if you would want to.Warning - I only 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 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 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 |
Agreed. To elaborate - if you type the following:
and set the language to
Yes, hash bang style provides per-script flexibility.
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.
I agree to a certain extent. There are some things
Can you clarify this in more detail? What's currently not working? |
? 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]
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
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
The text was updated successfully, but these errors were encountered: