Permission Denied When Building in Sublime Text 3 - windows

I am attempting to utilize Lua on Windows 10 with Sublime Text 3. When I attempt to build and run a script I receive the following error:
lua: cannot open C:\Program Files (x86)\Lua\5.1: Permission denied
I have added full permissions to the folder.
I am only attempting to run a simple print statement:
print("hello")
The expected result is hello output in the results window.

The build system that ships with Sublime for executing Lua programs looks like this:
{
"cmd": ["lua", "$file"],
"file_regex": "^(?:lua:)?[\t ](...*?):([0-9]*):?([0-9]*)",
"selector": "source.lua"
}
The important aspect here is that the command to be executed is lua with a first argument that is the name of the current file. From the error message you're seeing, Lua looks like it's trying to execute a directory instead of the name of a program. Or if you will, if this was a directory permission problem I would expect it to tell you the name of the file that it can't access, not the folder than the file is stored in.
It's also suspicious that the name of the folder is the install location for lua itself, and that the error message seems to indicate that it's lua itself generating the error.
Based on all of this, my guess would be that you didn't save your Lua script before you executed the command. That would cause $file to expand out to an empty string, making the first argument empty. Since the build is using cmd, internally windows is being told specifically to run a program named lua with an empty string as it's first argument.
It looks like the interpreter first tries to put the current working directory onto the filename and then execute it, and since the file name is empty, it ends up trying to execute a directory, which is where the permission problem comes from.
Once you save the file the first time and it has a name, Sublime will automatically re-save it every time you run the build as long as Tools > Save all on build is checked; that option won't prompt you to save brand new files that don't have names yet, though.

Related

I Cant get Ruby Packer to work and need a method to package a Ruby application

I have a ruby script that I run from the terminal, however I want to be able to double-click an icon like I would an application and run the script. I've looked at ruby-packer, but it isn't working for me.
What is the best option to accomplish this?
Im on a mac.
In terminal, I'm not at the directory of the .rb file because when I try to run ./rubyc from the directory containing the .rb file, I get the error command not recognized
When I run ./rubyc /RubyProjects/signOff.rb /signOff.out I'm able to get it to run, but the outfile file is called rubyc that just re-runs the same code when I double-click it. I'm at a loss for how to get it to work properly.
`
The -o parameter defines the output filename:
rubyc -o signOff signOff.rb

Does drag and drop leave the filename in an accessible place (macos)?

After I drag-and-drop a file, say from Finder, to say, Terminal running macos bash, is that value still accessible somewhere via a keyboard binding or an environment variable or some function or command? I know I could kill and yank the command line after the drag-and-drop lands on the command line, but I'd like something more direct if possible.
If you drag a file from Finder to the terminal the file name along with its path is displayed on the command line. It is not stored in any variable unless you write a code or script to read the file path and name. If you hit return after the name prints on the command line you'll probably get a "Permission denied" message (unless the name is an executable) but the path and file name will then appear in the history of commands. Typing history on the command line will show you the command you attempted to run. While not stored in a variable you should have temporary access to the info thru history.

Running python script on CMD which uses a folder to output results

I was using Pycharm as my editor to run the scripts since i need to add a task scheduler i had to test the code on the command prompt. Firstly this is the structure of my project.
When i try to run the following line
C:\Users\My_name\AppData\Local\Programs\Python\Python36-32\python.exe "C:\Users\My_name\PycharmProjects\FYP_CB006302\generateSummary.py"
I get this error,
From the knowledge i have i think it is because it doesn't recognize the path.
But when i change the directory to my project folder then give the path to python.exe and type generateSummary.py it works which was done as shown here.
However i highly doubt that this method can be used to task a schedule in Windows. Therefore, any ideas that would to run as shown in the beginning will be helpful.
The problem here is that when you use that line to run a particular script the folder which is causing the error is out of scope.
C:\Users\My_name\AppData\Local\Programs\Python\Python36-32\python.exe "C:\Users\My_name\PycharmProjects\FYP_CB006302\generateSummary.py"
In this case pickle_saves folder is out of scope. You can avoid this by giving a absolute path to that file in line 173. Where the absolute path is something like C:\user\documents\projects\pickle_saves\all_words

Why does one code execute from one folder but not the other?

I was just curious as to why with Windows O/S a simple Ruby file that prints one line to the command prompt can execute correctly from one path, but not the other.
Currently, I have said file in C:\Ruby193\test\lib saved inside the lib folder. When I go to the command prompt and set the path to C:\Ruby193\test\lib, I'd expect to see the code string be printed to the command prompt. However, nothing but an empty line is produced, and if I go up the path and set it to C:\Ruby193\test and execute the ruby file from there, it works just fine.
Does anyone have a sound explanation as to why it works that way? Would this also be the same case for a MAC O/S as well?

Build output from Visual Studio 2010 external tools in output window

I run a batch file as an external tool (by adding it in Tools->External tools) in VS2010 (I've checked the "Use Output Window" option). This batch file performs compilation as in VS command prompt. The project that I'm working on has makefiles for various folders, so I use the mk command to build.
In the batch file, I set up the VS environment and then run the following commands:
cd $directoryWhichContainsFileToBuild
mk
cd main //This directory contains the executable that is to be built
mk
I see the output of the first mk in the Output window but after that it just hangs. I also tried to use an echo after the first mk but even that doesn't get printed in the output window (the ones before it can be seen).
Somewhere I read that there is an issue with VS 2010 output window where it hangs after showing some output, although I couldn't really be sure that that is what's the issue here.
Do I need to enable some other VS setting? Has anybody else encountered this issue?
Thanks.
Update: I unchecked the "Use Output Window" and "Close on exit" option, and I see an extra statement: "Press any key to continue". On doing that however, their is no further processing of the batch file.
Update2: Got it to work by prefixing mk with "call".
Thanks all who tried.
It is always good in batch files to specify executables with full path and file extension instead of just the file name. This avoids often lots of problems.
Here was just mk used instead of mk.bat. Therefore on every compile the command line processor cmd.exe searches for mk.* and then checks if any of the found files have an extension listed in environment variable PATHEXT. The order of file extensions separated by a semicolon in PATHEXT defines the order of execution in case of a directory contains multiple mk.* files.
If a command being specified in a batch file not being an internal command of cmd.exe without path, command line processor searches first for a file with given name in current working directory. This is often one more cause of error. What is the current working directory on execution of the batch file?
Next if no file to execute can be found in current working directory, the command line processor searches in all folders being listed in environment variable PATH separated by semicolons.
So specifying in batch files edited only rarely an external application or another batch file with full path, file name and file extension, in double quotes if necessary because of 1 or more spaces in path or file name, helps command line processor to more quickly execute that application or batch file and avoids problems because of executable not found (unknown command).
Sure, when typing commands in a command prompt window, nobody wants to enter the executables with full path, name and extension. But for batch files it is always good to be not lazy and type files to be executed with full path and extension.
TripeHound has given already the explanation why the observed behavior occurred here.
If a batch file is executed from another batch file without using command call, the command line processor continues batch execution in the other batch file and does never come back. In a C/C++ program this is like using goto with the difference that parameters can be passed to the batch file containing the further commands to be executed next.
But running from within a batch file another batch file with call results in continuation of execution below the line calling the other batch file once the other batch file reaches end, except command exit is used in the called batch file without parameter /B.
So the solution here is using:
cd /D "Directory\Which\Contains\File\To\Build"
call "Path\Containing\Batch\File\To\Build\mk.bat"
rem With mk.bat not changing current working directory change working
rem directory to the directory containing the executable to be built.
cd main
call "Path\Containing\Batch\File\To\Build\mk.bat"
BTW: exit exits command processor, exit /B exits just current batch file. I'll give you three guesses why the parameter is B and not a different letter. Yes, B is the first letter of batch.
Writing as a separate answer instead of an update in the question itself as many readers see the header and skim to the answer: got it to work by prefixing mk with "call". (#TripleHound has also posted the conceptual reason for it in the comment above.)

Resources