Recover last command beginning with a string in GNU/Octave's command line - octave

I used to recover in Octave the last command beginning with a certain string by typing it and then pressing the up arrow key (likewise for Matlab). This behavior is not reproduced in my current Octave's command prompt (the raw one, as executed from a terminal). Meaning, I type something, press up, and the very last command shows up, no matter if a previous one starting with that string is in the stack.
Any way of configuring Octave to reproduce such behavior? It's really useful.
UPDATE
1. Octave version 3.8.1
2. a way to implement it is to press Ctrl-r, and then type (not really the same effect, as it searches for a command containing -not starting with- that string.)

This estrange behavior has been solved here, it's just a question of starting Octave without the -f option, which prevents loading the initialization files, including ~/.inputrc, responsible for the history-search-backward behavior.

Related

Using write access in Open command in TCL

How can i use write ('w') and read ('r') access while using command pipeline in open command in TCL.
when i do something like :
set f1 [open "| ls -l" w]
it returns a file descriptor to write to , say file1.
Now I am confused how can I put this file descriptor to my use.
PS : My example might be wrong, and in that case it'd be ideal if answer includes a programming example so that it'll be more clear.
Thanks
In general, the key things you can do with a channel are write to it (using puts), read from it (using gets and read), and close it. Obviously, you can only write to it if it is writable, and only read from it if it is readable.
When you write to a channel that is implemented as a pipeline, you send data to the program on the other end of the pipe; that's usually consuming it as its standard input. Not all programs do that; ls is one of the ones that completely ignores its standard input.
But the other thing you can do, as I said above, is close the channel. When you close a pipeline, Tcl waits for all the subprocesses to terminate (if they haven't already) and collects their standard error output, which becomes an error message from close if there is anything. (The errors are just like those you can get from calling exec; the underlying machinery is shared.)
There's no real point in running ls in a pure writable pipeline, at least not unless you redirect its output. Its whole purpose is to produce output (the sorted list of files, together with extra details with the -l option). If you want to get the output, you'll need a readable channel (readable from the perspective of Tcl): open "| ls -l" r. Then you'll be able to use gets $f1 to read a line from the subprocess.
But since ls is entirely non-interactive and almost always has a very quick running time (unless your directories are huge or you pass the options to enable recursion), you might as well just use exec. This does not apply to other programs. Not necessarily anyway; you need to understand what's going on.
If you want to experiment with pipelines, try using sort -u as the subprocess. That takes input and produces output, and exhibits all sorts of annoying behaviour along the way! Understanding how to work with it will teach you a lot about how program automation can be tricky despite it really being very simple.

Problem: GNU octave displaying every line of any program run in command window

I'm new to octave (and any kind of programing in general). It doesn't matter the code that I run, every time i do it the command window displays every line of it and every step, which can get overwhelming when doing cyclical algorithms. And this doesn't seem to happened to every other user I personally know. Even using exactly the same .m file, i get all the lines displayed and some other person doesn't.
I've searched in every configuration window possible, I tried reinstalling but nothing helped. And I've seen nobody else having this problem, is it just a configuration that I'm not aware of?
I'm running Octave 5.2.0 in Linux Mint 19.3
have you tried adding ";" at the end of your command lines ?
Basically if your code is something like:
x=5
y=4
Then your command window will display:
x=5
y=4
Whereas if you add the semicolons at the end of your code like so:
x=5;
y=4;
Then your values will be store and registered but nothing will be displayed in the command window.

How to search for a specific string in a process memory in lldb?

In reverse engineering, it is common trick to search a string and find it's occurrence in code. For example, when you want to bypass a registration or something. You will search the string that shows up on the popup message box, and the condition branch to decide you are register or not is near that address of the reference to that particular string. I can do it in hopper. But I am wondering can I do that in lldb?
I have searched for a couple of hours. And I looked at strings linux command, and image lookup. The most close one is memory find -s, but I don't know what address to pass to the command.
By the way, memory find seems to require the program to be run. Can I do it without setting a breakpoint?
For anyone that is looking. script import lldb.macosx.heap and there is a command call cstr_refs CSTRING, though I am not sure whether the const cstring literal will show up on Heap or not.

short commands are not working in customized wish shell

I have a customized in version of wish 8.6 shell with own environment loaded.
The issue is in native wish shell, short command work.
eg. packa r xxx for package require or stri e $str1 $str2 for string comparison.
But the same thing when i run in my customized shell, it says
invalid command name "packa"
But it works for the options for the command, as package re works for requiring the package.
What could be the possible cause, that wish is unable to resolve command name?
I know it it's bit difficult to answer for a customized shell but if someone could share probable causes based of logics, that would be of great help.
It sounds like you're not setting the global tcl_interactive to 1. That enables expansion of abbreviated command names as well as calling external programs without an explicit exec and a few other things (all of which is done in the unknown command handler procedure, or things it calls; if you want to customise things instead of working like tclsh does, look there).
Handling of unique prefixes of subcommand names is entirely separate.

Why Does Piping Binary Text to the Screen often Horck a Terminal

Imaginary Situation: You’ve used mysqldump to create a backup of a mysql database. This database has columns that are blobs. That means your “text” dump files contains both strings and binary data (binary data stored as strings?)
If you cat this file to the screen
$ cat dump.mysql
you’ll often get unexpected results. The terminal will start beeping, and then the output finishes scrolling by you’ll often have garbage chacters entered on your terminal as through you’d typed them, and sometimes your prompts and anything you type will be garbage characters.
Why does this happen? Put another way, I think I’m looking for an overview of what’s actually happening when you store binary strings into a file, and when you cat those files, and when the results of the cat are reported to the terminal, and any other steps I’m missing.
When you cat a binary file you can inadvertently send control characters to the terminal.
If a terminal application wants to send a beep for example, it sends the following binary to the terminal: 0x007 (SYS V only).
The same goes for colors, cursor position and others.
Start here: http://www.faqs.org/docs/Linux-HOWTO/Keyboard-and-Console-HOWTO.html
In particular, sections 3 (Console generalities) and section 4 (reseting your terminal).
It covers a bit more than you're talking about, but should give you what you need.
When you cat the binary data to the screen, the terminal tries to interpret that binary data into ASCII (or UTF). Some characters are capable of controlling the terminal. For example,
echo "^[[0;31;40m" # The first ^[ comes from pressing Ctrl+v, Esc
Will turn the background black and the foreground red. Use reset to return your terminal to normal.