I noticed that I can't combine --traditional options with the other one letter other options such as -i for example.
For example, when I have this as the first line in my octave .m file
#!/usr/bin/octave --traditional
Then it work. Octave starts ok and runs the script.
But when I try
#!/usr/bin/octave --traditional --silent --norc --interactive
It does not work. Error from octave. does not understand the options.
When I try
#!/usr/bin/octave --traditional -qfi
Also error. But this
#!/usr/bin/octave -qfi
works.
The problem is that --traditional does not have a one letter short cut like all the other options. This is the options I see
Options:
--debug, -d Enter parser debugging mode.
--doc-cache-file FILE Use doc cache file FILE.
--echo-commands, -x Echo commands as they are executed.
--eval CODE Evaluate CODE. Exit when done unless --persist.
--exec-path PATH Set path for executing subprograms.
--help, -h, -? Print short help message and exit.
--image-path PATH Add PATH to head of image search path.
--info-file FILE Use top-level info file FILE.
--info-program PROGRAM Use PROGRAM for reading info files.
--interactive, -i Force interactive behavior.
--line-editing Force readline use for command-line editing.
--no-history, -H Don't save commands to the history list
--no-init-file Don't read the ~/.octaverc or .octaverc files.
--no-init-path Don't initialize function search path.
--no-line-editing Don't use readline for command-line editing.
--no-site-file Don't read the site-wide octaverc file.
--no-window-system Disable window system, including graphics.
--norc, -f Don't read any initialization files.
--path PATH, -p PATH Add PATH to head of function search path.
--persist Go interactive after --eval or reading from FILE.
--silent, -q Don't print message at startup.
--traditional Set variables for closer MATLAB compatibility.
--verbose, -V Enable verbose output in some cases.
--version, -v Print version number and exit.
I am mainly interested in running octave code that is compatible with Matlab, so I'd like to use this --traditional option to make sure I keep the code compatible with Matlab in case I need to run the same code inside Matlab as well.
Or may be I can "turn on" this compatiblity mode once octave starts using a different command?
I am using GNU Octave, version 3.2.4 on Linux.
thanks
I don't think this is really an octave problem, per se. The Unix shebang notation in general is somewhat limited. I don't know the exact limits off the top of my head, but I'm pretty sure many implementations aren't happy if you add more than one option to the shebang line, which seems to be your problem.
Using a wrapper script is probably the canonical way to get around such problems.
To address your question of combining short and long options, Unix conventions don't allow for this. You could consider patching octave to add a short option for --traditional, if this is feasible for you. Alternatively, I'd imagine there's a way to specify the traditional behavior in the user or system-wide Octave configuration file, but this might not be that helpful if you need the script to work on systems you don't control.
Related
Sound as lazy as it is I was wondering if it's possible to open a file with sublime using (command line) and in the same command define the expected syntax.
Lets say on a mac we have the subl command installed, so running $ subl .bash_something will open the .bash_something then we have to chose the "shel script(bash)" syntax from the list. what would be really nice (for laze me) is to include the syntax to the command as an argument. i.e.
$ subl -x bash .bash_something
or something like that. this obviously doesn't work but I was wondering if there is similar solution or if its possible to include one
Unfortunately, there is no way that I can find to dynamically set the syntax from the command line. subl has the --command option, which allows you to run a Sublime command while loading the file, directory, or project indicated. However, the command to change the syntax of a view - set_file_type - takes an argument of the form ("syntax": "Packages/PackageName/SyntaxName.sublime-syntax") (or SyntaxName.tmLanguage). As far as I've been able to tell, you simply can't pass arguments to commands run via the command line. I've opened an issue to request an enhancement.
Now, this doesn't mean that all is lost. If you have just a few filetypes that are unknown to Sublime, open them, then select View -> Syntax -> Open all with current extension as... and select the syntax you want. If for some reason this isn't sufficient, or would like finer-grained control over exactly which filenames (not just which extensions) get opened as what, check out the ApplySyntax plugin. It allows you to use regexes to open exactly which file patterns you define as what syntax.
Commands can take arguments in Sublime 3 now. I was able to achieve this functionality with a bash function.
You can pass arguments to the --command option with inline JSON and escaped quotes. This command will change the syntax to Bash for the current active file in Sublime:
subl --command "set_setting {\"setting\": \"syntax\", \"value\": \"Packages/ShellScript/Shell-Unix-Generic.sublime-syntax\"}"
I created a simple bash function and sourced it in my .bash_profile to wrap these two commands together to activate/open a file then change the synax:
function subl_bash() {
subl "$1" && subl --command "set_setting {\"setting\": \"syntax\", \"value\": \"Packages/ShellScript/Shell-Unix-Generic.sublime-syntax\"}"
}
Mercurial's output may be localized. This is nasty when parsing command output and it actually may break such code. Is there some command line option or environment variable which can be used to force Mercurial to use English locale?
If you're writing script that interact with the mercurial executable then you probably want to look at the Command Server, or if you're writing python scripts hgapi.
These will give you interfaces which don't have localised strings in them.
For a linux shell (Bash, bsh, sh), use:
LANG=en_US hg <status/log/etc>
How can use Tcl command in windows-7 ? I want to copy one file to other locaiton using a .bat file.
How can use Tcl command in windows-7 ?
Windows (of all versions) has never come with a Tcl interpreter pre-installed, By far the simplest way is to get a copy of ActiveTcl installed.
Once you've got that installed, either run it interactively and just type your Tcl command in at the prompt, or use a text editor (like Notepad) to make a file (conventionally with extension .tcl) that contains the command or commands to execute; you'll probably be able to make the file run by just double-clicking on it.
I want to copy one file to other locaiton using a .bat file.
That's not really got much to do with Tcl. With Tcl, you would use:
file copy {C:\Where\To\Copy\From.txt} {C:\Where\To\Copy.to}
Note, we've put the filenames in {curly braces} here so that we can use backslashes; if we weren't doing that, we'd need to use double-backslashes instead (\\) or forward slashes (/).
The alternative, if you're really wanting to use a .bat file, is to look up what the cmd.exe commands COPY and (less likely) XCOPY do. But that's not a Tcl question.
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.
When you build Tcl/Tk by default it creates the files
tclsh85
wish85
However many programs call tclsh and wish. This is one fix for that
cp tclsh85 tclsh
cp wish85 wish
However, can you simply build tclsh and wish directly, perhaps using a configure argument?
This behavior is The Right Thing as it allows several versions of the interpreter and its libraries to coexist in the system. The system, in turn, does provide a way to "bless" one of the version as "default" — for instance, Debian provides "alternatives". In essence, usually a symlink with the "canonical" name is created pointing to the real executable, like /usr/bin/tclsh → /usr/bin/tclsh85. And with the "blessed" version available via such a symlink for the applications that do not care about the precise version of the runtime, certain other applications still can pick some specific runtime version by referring to the interpreter's real executable name.
This also provides an easy way to test an existing program against an experimental runtime version: you just run /usr/bin/tclsh86 /path/to/the/script.tcl instead of just running /path/to/the/script.tcl as usually which relies on the shebang to pick the interpreter.
A long time ago, the builds of Tcl and Tk used to work in the way you describe. It was changed to the current system (putting the version number in the name) to allow multiple versions to coexist more smoothly; this was a very strong demand from the user community at the time.
Symlink the version-less filenames to the real ones (or use the mechanism of your distribution) if you want to give up control over which version to use. Alternatively, use this (fairly horrible) piece of mixed shell/Tcl code at the top of your files:
#!/bin/sh
# Try with a versionless name \
exec tclsh "$0" ${1+"$#"}
# Otherwise, try with tclsh8.6 \
exec tclsh8.6 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.5 \
exec tclsh8.5 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.4 \
exec tclsh8.4 "$0" ${1+"$#"}
# Otherwise... well... give up! \
echo "no suitable Tcl interpreter" >&1; exit 1
This relies on the fact that Tcl, unlike the Unix shell, treats a \ at the end of a comment line as meaning that the comment extends onto the next line.
(Myself? I don't usually put in #! lines these days; I don't consider it an imposition to write tclsh8.5 myscript.tcl.)