How can I remove the Welcome screen on GNU Octave because it is boring to look at it every time.
I don’t know where and how to write silent and quiet I tried many ways.
You can just do
$octave --silent
For the furture, if you need to customize similar parameters (e.g. no gui etc), note that all of that can be seen with
$octave --help
Related
I can save individual variables fine in Octave, but i'm stuck when it comes to saving the entire workspace (ie, the whole screen with everything I've written on it)
eg
save file1
load file1
Doesn't seem to do anything
Any help greatly appreciated
David B
I do not think what you describe is a feature within Octave. You can save variables and the command history, see the description linked below, but I don't think its possible to save "the whole screen with everything I've written on it". Maybe if you better describe what elements you'd like to recover, specific instructions could be given.
Note that you aren't creating a "math document" like in Mathematica or GNU Maxima. This is a command interpreter, and recording commands entered and variables used is the usual extent of things to save.
https://phoxis.org/2013/04/06/save-work-environment-in-octave/
I had a need to capture the colored output of a long-running command line program, so I could easily share it with colleagues. Specifically, I'm running vagrant up, which generates colorful and useful output and I need to save this in a convenient format. My best solution so far uses two programs, aha and script, which are available as mainstream packages.
aha takes ANSI escape sequences and converts them to HTML markup. script fools your program into thinking it's outputting to your screen and not STDOUT, which normally disables color for many programs
I run my command in two steps:
script -q -c "vagrant up" temp.txt (-q removes status messages and -c tells script to run the command)
cat temp.txt | aha --black > output.htm (the --black flag makes the HTML background dark)
I'm pretty happy so far, but maybe this can be combined into one line? Any thoughts? Or better commands I could use? I'm aware the python ansi2html, but this seemed easier.
There are at least three major overviews that come up when searching for information on using sql with emacs (due to my insufficient reputation I can't 'afford' to link to them here).
I can find no mention in any of them of the need to set the variable sql-mysql-program when working with mysql servers. Yet I could not get M-x sql-mysql to work without following the advice from this SO question to set this variable as follows:
(setq sql-mysql-program "/path/to/your/mysql")
In fact, the only tutorials/documentation I've seen highlighting this variable are in the above SO question and another SO question about "emacs-how-to-use-ssh-tunnel-to-connect-to-remote-mysql" (which again I can't link to because of insufficient reputation.)
An alternate solution seems to be suggested here How to work with emacs and mysql, which suggests changing the value of the emacs exec-path.
The question is, which of these options is preferable, or is it simply a matter of taste?
And what is the significance of the fact that none of the above-linked overviews of sql/emacs mentions the need to get emacs to recognize the binary? Is there something wrong with my emacs?
I spent a long time combing the sql.el source to try to understand what was going on and I do see a (defcustom sql-mysql-program "mysql"…)but in my case at least that did not seem to do the trick (perhaps because I'm starting emacs up with -q option?).
PS. In case it matters, my M-x emacs-version is GNU Emacs 24.5.1 (x86_64-apple-darwin12.5.0, NS apple-appkit-1187.40) of 2015-05-01, which I am running on an older Mac (10.8.5)
Note that this can be generalised to a question of:
What do I do if Emacs can't find an executable?
which is where the exec-path list comes into play.
As noted in C-hig (emacs) Shell RET, the exec-path list is initialised from the environment variable PATH when Emacs is started (see also (emacs) General Variables), so there are multiple ways to populate that list with the values you need.
Using an absolute path to sql-mysql-program is also fine, but potentially less portable. It's up to you, really.
Are there any software packages or projects that provide the scripting language shells? I know there's csh for C programmers although not in a sense that it's primarily for programming, but for navigation and system administration. I was wondering if there is something inverted for this purpose? I.e. user logs into a shell that's primarily for programming and then for navigation (something like irb in ruby, but with navigation capabilities)?
I think you're misinformed if you think csh (tcsh) is for C programmers. It's just a shell like bash or ash or dash or ksh or zsh.
The R language provides a reasonably functional internal environment, complete with the ability to save/restore the "workspace" (your variables).
Python has a built-in interpreter, as does Maxima, and some Lisp/Scheme versions, plus you already mentioned irb.
You could also view vim or emacs as the type of programmer-centric shell you're talking about; both can be hooked up to run navigation commands and sysadmin-type stuff without forcing you to leave the editor.
I think the real answer to your question is "powerful shells provide their own scripting language".
Tcl's interpreter, tclsh, is really designed to be a shell. In fact, unlike Ruby where the interactive and non interactive shell are separate, tclsh works just like traditional shells like bash: if run without a script it enters interactive mode but given a script it enters batch mode.
But, it does suck in that it doesn't have readline built-in. So no up-arrow history or tab completion etc. But you can always run it using rlwrap:
rlwrap tclsh
which should give you readline capabilities.
However, I wasn't satisfied (partly because my system at the time didn't have rlwrap and partly because there were a few more features I wanted). So I wrote my own implementation of history and tab completion etc. Checkout my original Pure-tcl readline or the improved Pure-tcl readline2.
It really does act like an interactive shell complete with auto-executing external executables if a tcl command is unknown. And you can even execute interactive programs like vi, emacs or lynx from it. Because it automatically falls back to executing external commands, you can mix tcl and shell like:
foreach x [split [ps aux | grep apache] \n] {
puts [lindex $x 1]
}
This is great because tcl's syntax is much saner compared to bash and sh (ever tried to get out of '"\"\\\\"\ quoting hell in bash?). I personally like tcl but tcl is kind of a love-it-or-hate-it language. People who get it really love it and people who don't really hate it.
But even if you don't quite like tcl syntax I'd suggest you give it a try for this specific application because unlike other languages tcl really is designed to be used more as a command language than a programming language. Read I can’t believe I’m praising Tcl for some of the reasons why.
System navigation (and administrative tasks) are a really different application than programming, and it's hard to find a single shell that does both well. However, I'm guessing that what you're really asking for is a shell that
Lets you easily load the contents of a file and manipulate those contents in-process and with more dexterity than you get using bash and standard unix utilities.
In addition you want the convenience of accessing some of the normal commands for moving files around and navigating the file system.
The good news is that the standard scripting languages (e.g. Ruby, Perl) were meant to do #1 really well, and it's not hard to write/find a library to do #2 any of these langauges.
Because Ruby is what I'm familiar with, I'm going to give you a more concrete example of how you might accomplish this using Ruby.
To do this in Ruby, you would use irb (the Ruby REPL), and the FileUtils module which is part of Ruby's standard library.
To do this, start irb, then run
require 'fileutils'
include FileUtils
(you can put this in .irbrc if you'd like, but I'm not sure I'd recommend that.)
this allows you to have access to a number of the normal file manipulation commands through easy Ruby syntax. You can run other Ruby commands automatically yourself. To run other commands on your system, you're going to have to call them with system.
FileUtils doesn't include an ls command, because it wasn't really meant to be used interactively, so you'll need to write your own. I don't know a way to get good job control at all (that's not to say you couldn't write something though).
The only thing I warn you is that this workflow will be very different than other UNIX users, so you might want to think about being such a nonconformist is worth it, or whether you'd rather build experience that meshes well with other UNIX admins' working styles. It's probably better to get used to the core UNIX utils and the Bourne shell scripting language. (You could learn C-Shell if you want, but there is a well-known FAQ explaining the disadvantages of the C-shell for programming.)
You may want to take a look at IPython. It is an interactive Python shell (with filesystem navigation alongside other nice features) and it also provides a system shell profile to optimize its behavior for system shell usage.
CSH has nothing to do with C programming. It's serves the same functions as the Bourne Shell about equally well, but uses different syntax.
If you want C interpreter, I suggest using cint, which is part of CERN's ROOT system. But keep in mind that it's not useful in the least for system administration and navigation.
I'm sure with a little bit of work you could further extend Devel::REPL (Perl) to provide access to gnu coreutils,
Bash has lots of programming features that aren't ordinarily acknowledged, for example arrays and string manipulation options when expanding a shell variable. Some shells, like zsh or ksh have greatly improved programming features compared to the most common shells (namely bash or tcsh.)
I am in the process of building interactive front-ends to a
distributed application which to date has been used to run workloads
that had a batch-job like structures and needed no UI at all. The application is mostly written in Perl and C and runs on a mix of Unix and Windows machines, but I think this isn't relevant to the UI.
The first such frontend is going have a command-line user interface --
currently, I envision something similar to the CLIs of the Procurve
switches and Cisco routers that I have worked with.
Like modern network gear CLIs, commands are going to resemble
simple sentences, (i.e. show vlans ports 1-4) and the CLI will
have some implicit state, much in the way that Unix shells and
cmd.exe in Windows have environment variables and current working
directories. Moreover, I'd like to implement great tab completion that
is aware of the application's state as much as possible and I want to be able to do that with as
little application-specific code as possible.
The low-level functionality (terminal I/O) seems easy to implement on
top of GNU Readline or similar libraries, but that's only where the
real fun starts. So far I have looked at the Perl modules
Term::Shell
and
Term::ShellUI,
but I'm not convinced that I want to use either of them. I am still
considering rolling my own solution and at the moment I am primarily looking for
inspiration.
Can you recommend any application or library, regardless of
implementation language, that implements a good CLI from which I can
borrow ideas?
I suggest you take a look at the philosophy underlying Microsoft PowerShell. From the idea of piping typed objects between commands to the consistency of its commands and argument syntax, I think it can be a source of inspiration.
You could try having a look at libcli :
"Libcli provides a shared library for
including a Cisco-like command-line
interface into other software."
http://code.google.com/p/libcli/
BTW - I forgot to mention that it is GNU Lesser GPL and actually used by Cisco in some products.
As for your last sentence/question, I'm particularly fond of zsh completion and line editing (zle).