I use fossil to keep my shell script. But If I check in it and use it cross Windows & Linux, then the executable permission is missing of my shell script. How to add it back like svn's property setting?
As documented here. A manifest F-card (a file that's part of the check in) has up to four arguments. The (optional) third argument defines special access permissions associated with the file. If the letter 'x' is specified on this third argument then the file is defined as executable. Try setting the permissions of the file to executable:
chmod u+x,g+x,o+x myscript.sh
Then check the script in (you may have to modify it a bit, add a comment etc..). The script should be saved with it's executable bit sent in it's F-card entry the manifest. When it's checked out (on Linux) the executable bit should be set. Try not to modify and check-in the scripts on Windows or other file system that doesn't support Unix permissions.
Related
Is there is any way to make files/folders hidden during or install files action in install4j.
Like similar to .install4j folder in Installation folder.I am working on CentOS platform.
When install4j action replaces installer variables in files those are replaced as it is in text format,is there is any way to replace encrypted values or hide those replaced variables in shell script as it might contain sensitive information.
As of install4j 8, there is no action to make files hidden
Call context.registerHiddenVariable("<variable name>") in a script to tell install4j that an installer variable contains sensitive information. Its contents will not be written to the log file.
https://github.com/ninja-build/ninja/releases
I have downloaded the ninja-win.zip folder and extracted it. When I open it, there is a single .exe file in the entire folder. When I double click it a cmd window flashes for a split second. I have also tried running it as administrator, but the same thing happens. What I don't understand is, what am I expected to do with this .exe file?
You must open a terminal (cmd.exe on Windows) and type something like ninja -f /path/to/buld/file. You may also wish to modify the PATH environment variable so that Windows knows where to find the Ninja executable, depending on your setup.
You can simple download ninja.exe file from this Link
https://github.com/ninja-build/ninja/releases
After that you just have to add the path to your ninja.exe file to your windows environment variables and then you can use ninja commands from anywhere in windows.
1. Open cmd in your Project Directory
2. There are guides on the internet on where to save the Ninja.exe so that it'll be callable in Cmd without specifying directory. Either follow them or:
i, Specify Directory when Calling Ninja. Putting "ninja" in Cmd actually calls Ninja.exe and is the same as something like "C:\users\user1\downloads\Ninja". or:
ii, Save Ninja.exe in the same directory as Project.
3. proceed with rest of the command.
Therefore the Final Command would be:
"C:\users\user\downloads\Ninja.exe" -f "D:\Projects\Project1"
I need to run a program that requires certain inputs that are listed in a input.txt file. I want to be able to call up this file when I execute the program so I can modify the input.txt file if needed before executing the rest of the code.
I'm running on Mac OS X.
What I have is:
call system('notes input.txt')
I get the following message :
sh: notes: command not found
Is there a special way to call the app notes, or is my error somewhere else?
you're not specifying a full filesystem path in the string ("notes input.txt") which the SYSTEM function sends to a command shell. That means you're hoping there's a binary named "notes" somewhere in your shell's $PATH , and your shell is telling you that's not true. The Notes app is not named "notes", and it doesn't live somewhere pointed to by the shell's $PATH. That's why you get this error message. Try passing to the shell the full path of both the binary you want to run, and the file you want to edit:
CALL SYSTEM("/Applications/Notes.app/Contents/MacOS/Notes /path/to/input.txt")
(NB: that path is where the Notes app lives on my Mac; YMMV.)
Try
call system("/Applications/TextEdit.app/Contents/MacOS/TextEdit /path/to/input.text")
The /Applications/TextEdit.app location is a bit misleading as it is actually a folder. In Finder if you option-click on it you can select to view contents (Not sure of the exact wording of the option as I don't have my mac on me at the moment). Alternatively, cd /Applications/TextEdit.app; ls to view the contents. The executable should be stored in a subdirectory as shown above.
I am trying to configuring HTTPS based on this tutorial:
Configuring HTTPS for your Elastic Beanstalk Environment
I am stuck at the following section:
To set the OpenSSL_HOME variable
Enter the path to the OpenSSL installation:
c:\ set OpenSSL_HOME=path_to_your_OpenSSL_installation
My openSSL is installed in c:\OpenSSL, so would I write set OpenSSL_HOME=C:\ OpenSSL?
Do I enter such command in Command Prompt?
Finally this step:
To include OpenSSL in your path
Open a terminal or command interface and enter the appropriate command for your operating system:
c:\ set Path=OpenSSL_HOME\bin;%Path%
My %Path% here would be what?
My openSSL is installed in c:\OpenSSL, so would I write set OpenSSL_HOME=C:\ OpenSSL?
Yes, but without the space after C:\:
set OpenSSL_HOME=C:\OpenSSL
Do I enter such command in Command Prompt?
You can. Do note, however, that with this approach, you would be modifying the OpenSSL_HOME environment variable for that particular command window only, and it would be accessible only to processes that are run from that same window. As soon as you close the window, your variable disappears.
If you need to make it persistent, especially through reboots, you have to configure the OS's global environment instead. On Windows, right-click on My Computer, go to Properties, Advanced system settings, Environment Variables, and add a new entry for your variable.
My %Path% here would be what?
That is an existing environment variable. You are modifying the existing Path, so by including %Path% to the end of your assignment, you preserve the existing Path so that existing paths can still be accessed.
Fir, note that the example in the documentation is wrong. It should be this instead:
c:\ set Path=%OpenSSL_HOME%\bin;%Path%
With that said, lets say for example that Path already contains a value of C:\Windows\;etc. After the assignment, the new Path will be C:\OpenSSL\bin;C:\Windows\;etc
I'm new to deploying programs written in C/C++ on Linux and I'm wondering what you'd do in this situation.
I have a binary file (compiled with GNU Make) that needs to read a config file (such as myprogram.conf). But when I write a Makefile to deploy this file to /usr/bin/, where should the config file go? And how does the executable know where it is?
You have endless options, but the best way depends on a couple of things. First, is it a user-specific configuration file, or is it global to all users?
If it's user specific, you could, for example, keep it in ~/.myprogram/config.file and have the program check there. As a service to your users, it's up to you to decide what to do if it's not found -- perhaps copy a default config there from somewhere else, or generate a default, or use hard-coded default options, or display a configuration wizard, or just fail. That's entirely up to you.
If it's global, the traditional place to put it on Linux is in /etc, e.g. /etc/config.file or /etc/myprogram/config.file. See Linux File System Structure. You will generally always have a /etc on Linux. Handling a situation where the file does not exist is the same as above - there's no "right" way to handle that, it's based purely on how convenient you want to make it for a user.
What I usually do for global config files is put them in /etc/wherever on install, have the program default to loading the config file from /etc/wherever, but also give a command line option to override the configuration file (especially useful for testing or other situations).
What I usually do to handle missing config files depends entirely on the application. I'll generally either have hard-coded defaults (if that's appropriate) or simply fail and direct the user to some documentation describing a config file (which I find adequate in situations where my installer installs a config file).
Hope that helps.
It kind of depends on what the configuration parameters are, and whether they are "per system" or "per user" or "per group" or ...
System configurations typically live somewhere in /etc/.... In the same directory that the program lives is a very good place too.
User confgiurations, in the home directory of the user.
Group configurations are the trickiest, as you'll probably need to come up with a scheme where there is a configuration file per "group". /etc/myprog/groups/<groupname>/config or something similar would work.
On Linux, the usual location for configuration files is '/etc', so it is acceptable to deploy a configuration file like /etc/myprog.conf. That requires root privileges however. Other good options include putting a configuration file in the user's home directory, making it something like ~/.myprog.conf or ~/.myprog/.conf to use a folder where you can have several config files, a cache or something else that you want.
As for how the executable knows where the file is, one solution is to look for the file in several common locations. For example, if you decided to place your config in the user's home directory, look for it there first, if not found, look under /etc. And allow a special command line argument that would let a different config file to be loaded. So, say, an invocation of myprog can check for a config file in the home folder, but myprog -c /some/path/config will use /some/path/config as the file. It's also a good idea to have some default settings that you can fall back to if there is no valid config file anywhere.
The config file can go anywhere, but I'd try to put it in the same directory as any other files the program will read or write.
As for how the executable will find it, I'd pass the config file's path to the executable on the command line as an argument, with a default value of "." (which is the current directory, the one you're in when you launch the executable).