How to make CLI password masking in Lua? E.g. when I write password it changes into asterisk or nothing is shown at all? I need platform-independent solution as my script will be used in Java application.
In plain Lua, the answer is simple: you can't.
Since Lua is written in ANSI C you can not get characters from the command line without having to press enter. You can however make use of bindings to libraries like curses.lua which comes with luaposix.
Or if you can assume you'll have an ANSI VT, you can resort to a hack like this:
io.write("\027[s") -- save cursor position
l=io.read()
io.write('\027[u',('*'):rep(#l),"\n") -- rewind to where we were, and fill with the correct amount of stars
print("pst, I got", l, "but don't tell anyone!")
More info about ANSI terminal control
But if it'll be used for a Java application, why not use Java for the password prompt. I guess their support and control of the cli would be better and cross-platform...
Related
How could I automate interactions with command line programs that expose a text terminal interface with Perl 6 for testing purposes?
If you want to use Perl 6 to automate execution or testing of console applications, I think you're going to use NativeCall to interact with the expect library. Once expect is installed, man libexpect will show its API documentation, though the way of accessing the documentation (such as the manpage name) may differ per package distribution.
Expect has APIs to launch a program, wait for text to appear on the (emulated) console (to "expect" text), and send text to the console (to emulate typing). The most common use case is to automate programs which require password input. Expect is often scripted--it is an interpreter--but there's no reason not to use it from a higher level programming language.
Edit: I somewhat answered the wrong question. The OP is interested in testing Perl 6 modules with Perl 6. That said, using expect to launch a second Perl 6 interpreter which uses the module is still the strongest, most strict way to test the application. You don't need to know what type of terminal library the module uses, because expect should be compatible with nearly all of them. You can send text to the STDIN pipe of a subprocess, but that's not as strong as the subprocess (console) communication you can get from expect. I don't know if there's a way to hijack whichever terminal library the module uses and communicate with it directly.
If it's just a plain interface, you could just run the program and collect output. The currently-experimental Testo module has is-run routine. You could use that directly, or if experimental status is bothersome, copy the guts of it into your own helper routine.
Take a look at Sparrow6 Task Check Language - Perl6 based DSL to verify text output. I've done a lot terminal apps testing using it.
I often heard Snippet Expansion by an IDE, but I searched and couldn't figure out that it means. Could you explain what it is?
Snippet expansion allows you to type short sequences of characters, hit another key, and have it expanded out into a larger amount of code. This is useful for quickly writing common chunks of code.
The above image shows me writing a simple C++ program with the use of snippet expansion. I include the header, I just write inc and hit tab. To write the main function, I write main and hit tab. Similarly for the for loop and cout expression.
It means typing in a sequence of characters, e.g. "if()", pressing a keystroke, and having the IDE look up in a database for the replacement, e.g. "if(|) {\n}", and putting it in the editor in place of the sequence.
It is the feature of some ide's to expand on a certain sequence of keys which is useful to type something faster on not type it at all. Like when you start typing for and it expands to a for loop.
Personally, I use vim, and snipMate.vim enables just that. The example video is here.
I sometimes test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality. Of course, since my code is in development there are bugs, and frequent restarts of the interpreter are required. This isn't too painful when I've only executed a couple of interpreter lines before restarting: my key sequence when the interpreter restart looks like Up Up Enter Up Up Enter... but extrapolate it to 5 or more statements to be repeated and it gets seriously painful!
Of course I could put my test code into a script which I execute with python -i, but this is such a scratch activity that it doesn't seem quite "above threshold" for opening a text editor :) What I'm really pining for is the Ctrl-r behaviour from the bash shell: executing a sequence of 10 commands in sequence in bash involves finding the command in history (repeated Up or Ctrl-r for a search -- both work in the Python interpreter shell) and then just pressing Ctrl-o ten times. One of my favourite bash shell features.
The problem is that while lots of other readline binding functionality like Ctrl-a, Ctrl-e, Ctrl-r, and Ctrl-s work in the Python interpreter, Ctrl-o does not. I've not been able to find any references to this online, although perhaps the readline module can be used to add this functionality to the python prompt. Any suggestions?
Edit: Yes, I know that using the interactive interpreter is not a development methodology that scales beyond a few lines! But it is convenient for small tests, and IMO the interactiveness can help to work out whether a developing API is natural and convenient, or too heavy. So please confine the answers to the technical question of whether readline history-stepping can be made to work in python, rather than the side-opinion of whether one should or shouldn't choose to (sometimes) work this way!
Edit: Since posting I realised that I am already using the readline module to make some Python interpreter history functions work. But the Ctrl-o binding to the operate-and-get-next readline command doesn't seem to be supported, even if I put readline.parse_and_bind("Control-o: operate-and-get-next") in my PYTHONSTARTUP file.
I often test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality.
Stop using this pattern and start writing your test code in a file and your life will be much easier.
No matter what, running that file will be less trouble.
If you make the checks automatic rather than reading the results, it will be quicker and less error-prone to check your code.
You can save that file when you're done and run it whenever you change your code or environment.
You can perform metrics on the tests, like making sure you don't have parts of your code you didn't test.
Are you familiar with the unittest module?
Answering my own question, after some discussion on the python-ideas list: despite contradictory information in some readline documentation it seems that the operate-and-get-next function is in fact defined as a bash extension to readline, not by core readline.
So that's why Ctrl-o neither behaves as hoped by default when importing the readline module in a Python interpreter session, nor when attempting to manually force this binding: the function doesn't exist in the readline library to be bound.
A Google search reveals https://bugs.launchpad.net/ipython/+bug/382638, on which the GNU readline maintainer gives reasons for not adding this functionality to core readline and says that it should be implemented by the calling application. He also says "its implementation is not complicated", although it's not obvious to me how (or whether it's even possible) to do this as a pure Python extension to the readline module behaviour.
So no, this is not possible at the moment, unless the operate-and-get-next function from bash is explicitly implemented in the Python readline module or in the interpreter itself.
This isn't exactly an answer to your question, but if that is your development style you might want to look at DreamPie. It is a GUI wrapper for the Python terminal that provides various handy shortcuts. One of these is the ability to drag-select across the interpreter display and copy only the code (not the output). You can then paste this code in and run it again. I find this handy for the type of workflow you describe.
Your best bet will be to check that project : http://ipython.org
This is an example with a history search with Ctrl+R :
EDIT
If you are running debian or derivated :
sudo apt-get install ipython
How can I achieve auto-completion of key words and directories by typing TAB (or something else) in TCL shell , tclsh.
You need to find a copy of tclreadline, or switch to using tkcon (a graphical terminal written in Tcl that acts as a console) if using a GUI app is acceptable at all. FWIW, I can definitely recommend tkcon; the only reason I don't use it that much is because I'm often working with a custom build of Tcl that's hooked up to other things.
I am not a fan of using SQL*PLUS as an interface to Oracle. I usually use yasql, but it hasn't been updated since 2005 and can do with some improvements. A quick Google search shows yasql and SQLPal. I am using linux, so SQLPal is not an option.
Are there any alternatives out there, or am I stuck with an interface that I do not like or one that is no longer maintained?
I presume that you want a low-overhead method of knocking out queries, but want more functions than SQL*Plus provides? Why not use Oracle's SQL Developer? It's free.
Install, make a new connection to your database, then just start typing a script. Press F5 to run it (or just the part of the script that you've highlighted).
Take a look at gqlplus. It wraps sql*plus on linux and makes it more user-friendly by adding things like command history, table name completion and so on.
Emacs can provide so much more powerful text editing features and functionality beyond the default SQL*Plus command-line interface.
Here are a few links on how to use Emacs as a wrapper for SQL*Plus:
Emacs and Oracle
EmacsWiki:SqlPlus
TOAD is pretty expensive, but you can download a 90-day trial from the Quest site to see if it's got the feature set you want (don't be fooled by the "freeware" title - it's only free for 90 days, and then it expires, which definitely makes it shareware):
http://www.toadworld.com/Freeware/ToadforOracleFreeware/tabid/558/Default.aspx
Another options is a tool I've seen on CodeProject:
http://www.codeproject.com/KB/database/OQuery.aspx
It's in .NET, so you'd have to see if it compiled on Mono, but it might be worth a shot. I haven't used either tool (Toad or this one), since I'm a SQL Server guy, but I've heard good things about Toad.
If it's command-line you want, I'd recommend rlwrap to go with sqlplus; it gives you line-editing capabilities and command history, making sqlplus a somewhat usable tool.
You could try PL/SQL developer from allroundautomations, there is a trial available and the price is much lower than TOAD.
Regards
K
Take a look at Senora. This tool is written in Perl and therefore is cross platform. Also Senora is free, extensible and intends to be your primary Oracle shell. You can extend Senora easily by providing you own plugins. Senora attempts to provide a friendlier output formatting than sqlplus. Columns tend to be only as wide a really needed.
Another interesting alternative is SQLcl. It provides in-line editing, statement completion, command recall, DBA stuff (e.g. startup, shutdown) and also supporting your previously written SQL*Plus scripts.
It depends what you are looking for.
If it is a GUI query tool, then Oracle have their free SQL Developer product (though it has a hefty footprint). There's a few free cross-database ones too. I like SQUirrel SQL client myself. There's also DBVisualiser and a few others.
JEdit is an editor that has a DBConsole plugin for running database queries and DML/DDL.
They are all java based so run most places.
If you like a command line, check out sqlpython (the developer has identified a couple of others too)
I like SQL Developer. It's free, has an intuitive UI, and runs on Windows, Mac, and Linux. It also supports many sql*plus commands and supports version control
Apparently Oracle itself has phased out sql*plus and replaced it with SQLcl, which supports more modern features such as history, formatting, etc: https://www.oracle.com/database/technologies/appdev/sqlcl.html.
open source version of TOAD is TORA:
tora.sourceforge.net
If you're the VIM type kind of guy then I'd look into Vorax. It is basically a VIM wrapper around SQL*plus.
Have used both Toad & SQL Navigator, and I love the stability SQL Navigator has.
i like sqlsh
alias sqr='sqlsh -d DBI:Oracle:MYSERVER.COM -u USER -p PASSWORD'
toad from quest software if you can pay for a license
sql squirrel if you can't.
I used my own tool ocimlsh in conjunction with rlwrap.
I just use socat to add readline support to sqlplus. History and a working backspace key actually turn sqlplus into a pretty decent tool.
In my .bashrc:
function sqlplus {
socat READLINE,history=$HOME/.sqlplus_history EXEC:"$ORACLE_HOME/bin/sqlplus $(echo $# | sed 's/\([\:]\)/\\\1/g')",pty,setsid,ctty
status=$?
}
You might see alternatives that alias sqlplus to socat, but you will quickly discover that doing so prevents you from invoking sqlplus with its various command line options.
CAVEAT: Be sure to set $HOME/.sqlplus_history permissions to 0600. Passwords that you type end up in the history file. You might also consider adding cat /dev/null > $HOME/.sqlplus_history to your .bash_logout.