I am writing a code in tcl using windows. When I try to create a folder using this command
set FileName "GVOutPut";
file mkdir $FileName;
i get this error:
can't create directory "GVOutPut": permission denied
while executing
"file mkdir $FileName"
how could i solve this problem?
You should check that the current directory (puts [pwd]) is the directory where you expect the new directory to be created in instead of being somewhere where normal users can't write by default. It is very easy for that to be different in a GUI program than for a text program; the defaults vary (due to the different ways that they're launched by the OS). It often pays to use full pathnames in your programs, or to make things all relative to a known location. You can use the cd command to set the current directory.
Alternatively, launch the program from an elevated shell. But you probably don't want that option as it has a lot of non-trivial consequences.
Related
I'm new to servers and programming in general, and I have a question regarding remote acces to a server, and how much I can actually do on it.
The thin is I have a working program on a linux server, which I acces with my windows machine using mobaxterm. I can acces the server, I see folders and a cmd line, where I can compile a makefile. Everything runs well, however when I run the makefile it just compiles, and doesn't do anything. No error messages, but also no opening of a program. I don't understand anything. Is it a delimitation of the servers structure, that it can only store files on it?
When you compile under linux using a make, it produces an executable but does not run it. Make builds executable objects, but it does not run them. You should include your makefile in the question (reduced to a minimum if it is large). Inside it, you will see that it generates a executable file with a specific name. To run it, you need to invoke this from the command line.
To find out what it is building, a quick way is to type "make clean" (press enter of course) to clean up any built objects. Then type the "ls" command to see what is in your directory.
Next, build the program with the "make" command, then type "ls" to see what has been added. Ignore any new files that end in .o or .a or .so and look for any new files. These are the files built by make and at least one of them is the program you built.
Assuming you found a new file called "myprogram". To run it, type:
./myprogram
I just installed Sublime-jshint (and the requisite node.js + jshint) but get this error when I try to invoke JSHint from within ST2:
[Errno 2] No such file or directory
[cmd: [u'jshint', u'PATH-TO-THE-JS-FILE-I-AM-LINTING', u'--reporter', u'/home/cmg/.config/sublime-text-2/Packages/JSHint/reporter.js']]
[dir: DIR-MY-JS-FILE-IS-IN]
[path: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/cmg/bin]
[Finished]
The final item in the given path is in the home dir of my user (cmg), so it's been customized somehow... but I don't recall how, so I don't know how to add the dir I need (~/node_modules/.bin).
I've added it to $PATH in my shell (via both .bashrc and .bash_profile) but ST2 doesn't pick it up.
(I'm on Ubuntu 14.04. All the usable stuff I've found via Google on this subject has been either OS X specific or related to ST's build system).
Basically, the exec command, which the jshint package uses internally, allows you to set/extend the PATH of the spawned subprocess. (docs)
The package actually uses this path argument on OSX, but has it hardcoded (I am partly guilty of that as I rewrote the command because it was just horrible before). It should allow for a setting to specify the path to your jshint executable, so I suggest you create an issue for that.
I don't know why ST dosn't pick up your PATH from somewhere else since I have very little experience with that.
Open /etc/profile in Sublime (using sudo) and add the following line at the very bottom:
export PATH=/home/cmg/node_modules/.bin:$PATH
and save the file. Restart completely, and your PATH should be updated.
I am trying to run a very simple tcl script
package require Expect
spawn sftp user#host
the error I get is
The system cannot find the file specified.
while executing
"spawn sftp user#host"
The only reason I see it's that sftp path should be specified somehow. I call this from a batch script and I've also tried changing the directory to sftp location before calling the script but the error is still the same.
By far the most likely cause of the issue here is that the sftp program is not in a directory that is on your PATH. The concept is almost the same across platforms, but with some minor niggles.
Working with the Unix PATH
Check to see if sftp is available in a PATH-known directory by typing:
which sftp
At your shell prompt. It should respond with the location of the sftp program, but if it isn't found then you get no response at all. If it isn't found, you'll need to find it yourself and add its location (strictly, the directory that contains the program) to the PATH. Find the program with something like:
locate sftp
Or (very slow!):
find / -name sftp -print
To append a directory to the PATH, do this in your shell:
PATH=$PATH:/the/dir/to/append
You can add a directory within the Expect script too (as long as it is before the spawn, of course!):
append env(PATH) : /the/dir/to/append
Working with the Windows PATH
On Windows, use Windows Search (Windows+F IIRC) and look for a file called sftp.exe (there's also a command line search tool, but I forget how to use it).
With the Windows PATH, a little more care is required:
append env(PATH) ";" {C:\the\dir\to\append}
# Or this...
append env(PATH) ";" [file nativename C:/the/dir/to/append]
Which is to say, the Windows PATH uses a different separator character (because : is used for separating drive names from directory parts) and the native name of the directory must be used, rather than the somewhat-more-convenient forward-slash variation (the backslashes interact with Tcl's syntax, hence the {braces}). Forward-slashes can be used provided you use file nativename to convert before appending, as in my second version.
Some Tcl Techniques that can Help
You can use the Tcl command auto_execok to find out whether a program is on your PATH or not. For example:
puts [auto_execok sftp]
However, for some commands (notably start on Windows) you get a more complex response; the command really exists as part of the code that supports interactive Tcl usage, describing how to run some external program which can sometimes be a lot more complex than it appears to be at first glance. Still, it approximates to a cross-platform version of which as listed in the beginning of this answer...
Tcl 8.6 provides $tcl_platform(pathSeparator) variable as a way to get the PATH element separator character (a : or ;, depending on platform). Probably doesn't help you though, as 8.6 hasn't yet been distributed as widely as previous versions.
I'm working on a simple TCL script that makes a few Tk dialogs appear and then compresses a file given by argv. It works just fine from the terminal by running "./script file", but since it's a graphical wrapper for a command-line utility, I want it to run from the right-click menu in a file manager.
I copied it to /usr/bin and used Caja's "Open With Other Application..." option on a random file (no spaces in the path), and entered the name of my script as the application to use. When I tried to open the file this way, there were no dialogs and no archive.
However when I tried to run the script from the terminal again, without the "./", it still worked.
What needs to be done to run a TCL script on a file from the right-click menu and still be platform independant?
Maybe you could start with determining wether Tcl or the file manager is the problem. Write a shell script...
#!/bin/sh
exec rm -- "$#"
...make it executable with chmod +x and try to use it as an "other application" on a file you don't care about. If the file isn't erased, Tcl isn't to blaim.
I have fixed the script in question. I don't know why the dialogs broke or why they are working now, but the archive was apparently failing to appear because the script's working directory was automatically set to my home folder by the file manager.
The code below is what I used to direct my script to the right folder. It changes the working directory to the one containing the file that the script is being run on.
cd [file dirname $argv]
Once I set that, most of my issues seemed to be resolved, and I can now continue dveloping my script.
I'm trying to create an RPM in Fedora 15 that will install my software, but in order for my software to work correctly once installed, I also need to edit other (configuration) files on the system, add users/groups, etc. Performing some of these tasks is only allowed by the root user. I know to never create an RPM as the root user, and I understand why that is such a bad idea. However, if I add shell script statements to my spec file (%post, %prep... any section) to edit the necessary files, add users/groups, etc., my rpmbuild command fails with message "Permission denied" (not surprisingly).
What's the best way to handle this? Do I have to tell my users to install my package first, and then perhaps run a shell script as root to configure it all? That doesn't seem very elegant. I was hoping to allow a user to do everything with one simple command such as 'yum install mysoftware'.
Much of my research suggests that perhaps this shouldn't even be done via RPM. I've read many parts of Maximum RPM, and lots of other good resources, but haven't found what I'm looking for. I'm new to creating RPMs, but have already been able to successfully create a simple spec file for my software... I just can't get everything configured properly after the package is unzipped and installed to the correct location. Any input is greatly appreciated!
useradd should be run in %pre and shouldn't run during rpmbuild. That's the standard way of doing it. I would recommend the packaging guidelines and specifically the section on users and groups.
The %pre section of your RPM .spec file should check for all the conditions necessary for your software to install.
The %post section of your RPM .spec file should make all the modifications needed for your software to run.
To avoid file permission errors in the %post section of your RPM .spec file, you can set the file permissions and ownership in the %files section. That way, the user who installs the RPM has the appropriate permissions to modify the configuration files.
%install
# Copy files to directories on your installation server
%files
# Set file permissions and ownership on your installation server
%attr(775, myuser, mygroup) /path/to/my/file
%pre
# Check if custom user 'myuser' exists. If not, create it.
# Check if custom group 'mygroup' exists. If not, create it.
# All other checks here
%post
# Perform post-installation steps here, like editing other (configuration) files.
echo "Installation complete."