In a mongo shell window, I'd like to periodically run a script that will display various stats on the database activity, before displaying the stats, I'd like to clear the screen. There is a "cls" command in the mongo shell, but I am not able to execute it from within the javascript.
function stats () {
while(1) {
cls;
print("display stats");
sleep(5000);
}}
The line with the "cls" is not recognized.
Thank you for any suggestions,
Gary
At the first glance it seemed that you won't be able to do it. According to the docs here: "You cannot use any shell helper (e.g. use , show dbs, etc.) inside the JavaScript file because they are not valid JavaScript.".
One option was to fill the screen with empty lines:
function clearIt () { for(var i = 0; i < 100; i++) { print() } }
clearIt()
However, thanks to #NeilLunn pointing it out there seems to be a solution:
function clearIt () { run('clear') }
clearIt()
This would execute system command which will clear your terminal screen. I don't know how reliable it is (see man clear -> depends if it can figure out how to clear screen) and this works only on POSIX systems. On Windows you would have to replace clear with cls:
function clearIt () { run('cls') }
Additional:
I looked up the source code of mongo shell (src/mongo/shell/linenoise.cpp). Here is how it clears the screen:
void linenoiseClearScreen( void ) {
#ifdef _WIN32
COORD coord = {0, 0};
CONSOLE_SCREEN_BUFFER_INFO inf;
HANDLE screenHandle = GetStdHandle( STD_OUTPUT_HANDLE );
GetConsoleScreenBufferInfo( screenHandle, &inf );
SetConsoleCursorPosition( screenHandle, coord );
DWORD count;
FillConsoleOutputCharacterA( screenHandle, ' ', inf.dwSize.X * inf.dwSize.Y, coord, &count );
#else
if ( write( 1, "\x1b[H\x1b[2J", 7 ) <= 0 ) return;
#endif
}
In case you feel like trying to implement your own screen cleaning function by filling screen with chars.
> help admin
ls([path]) list files
pwd() returns current directory
listFiles([path]) returns file list
hostname() returns name of this host
cat(fname) returns contents of text file as a string
removeFile(f) delete a file or directory
load(jsfilename) load and execute a .js file
run(program[, args...]) spawn a program and wait for its completion
runProgram(program[, args...]) same as run(), above
sleep(m) sleep m milliseconds
getMemInfo() diagnostic
This shows the run and runProgram commands along with some other helpers. The program argument is a string.
Related
I want to create a Neovim plugin that automatically runs a test suite whenever a file is saved. Here's an overview:
If I save a Rust file, run cargo test
If there's not a buffer opened for the test output, automatically create the buffer
Mark that buffer as readonly
If I save another file, reuse the existing buffer
If the buffer is quit (e.g., :q), create a new buffer on the next test run
However, I'm currently facing three issues:
I cannot detect if when I quit the buffer
When the test output is longer than the buffer height, the buffer will not scroll down
When I want to quit Neovim, it asks me to save all these temporary buffers (which I don't want to do)
How can I resolve these issues? For reference, here's my code:
local buffer_number = -1
local function log(_, data)
if data then
vim.api.nvim_buf_set_lines(buffer_number, -1, -1, true, data)
end
end
local function open_buffer()
if buffer_number == -1 then
vim.api.nvim_command('botright vnew')
buffer_number = vim.api.nvim_get_current_buf()
end
end
local function autotest(pattern, command)
vim.api.nvim_create_autocmd("BufWritePost", {
group = vim.api.nvim_create_augroup("autotest", { clear = true }),
pattern = pattern,
callback = function()
open_buffer()
vim.api.nvim_buf_set_lines(buffer_number, 0, -1, true, {})
vim.fn.jobstart(command, {
stdout_buffered = true,
on_stdout = log,
on_stderr = log,
})
end
})
end
autotest("*.rs", { "cargo", "test" })
P.S. I know there are several existing plugins for testing. I'm creating my own because I want to learn how to write neovim plugins.
I gave it my best shot. I believe this addresses your questions and does what you're aiming to do.
local buffer_number = -1
local function log(_, data)
if data then
-- Make it temporarily writable so we don't have warnings.
vim.api.nvim_buf_set_option(buffer_number, "readonly", false)
-- Append the data.
vim.api.nvim_buf_set_lines(buffer_number, -1, -1, true, data)
-- Make readonly again.
vim.api.nvim_buf_set_option(buffer_number, "readonly", true)
-- Mark as not modified, otherwise you'll get an error when
-- attempting to exit vim.
vim.api.nvim_buf_set_option(buffer_number, "modified", false)
-- Get the window the buffer is in and set the cursor position to the bottom.
local buffer_window = vim.api.nvim_call_function("bufwinid", { buffer_number })
local buffer_line_count = vim.api.nvim_buf_line_count(buffer_number)
vim.api.nvim_win_set_cursor(buffer_window, { buffer_line_count, 0 })
end
end
local function open_buffer()
-- Get a boolean that tells us if the buffer number is visible anymore.
--
-- :help bufwinnr
local buffer_visible = vim.api.nvim_call_function("bufwinnr", { buffer_number }) ~= -1
if buffer_number == -1 or not buffer_visible then
-- Create a new buffer with the name "AUTOTEST_OUTPUT".
-- Same name will reuse the current buffer.
vim.api.nvim_command("botright vsplit AUTOTEST_OUTPUT")
-- Collect the buffer's number.
buffer_number = vim.api.nvim_get_current_buf()
-- Mark the buffer as readonly.
vim.opt_local.readonly = true
end
end
function autotest(pattern, command)
vim.api.nvim_create_autocmd("BufWritePost", {
pattern = pattern,
callback = function()
-- Open our buffer, if we need to.
open_buffer()
-- Clear the buffer's contents incase it has been used.
vim.api.nvim_buf_set_lines(buffer_number, 0, -1, true, {})
-- Run the command.
vim.fn.jobstart(command, {
stdout_buffered = true,
on_stdout = log,
on_stderr = log,
})
end
})
end
autotest("*.rs", { "cargo", "test" })
I added some comments to help explain each step but specifically for each of your problems:
I cannot detect if when I quit the buffer
Since you already have the buffer number, you can query to see if it's still visible. Just by using the same name when creating the new buffer we an reuse any existing ones.
When the test output is longer than the buffer height, the buffer will not scroll down
This was tricky, and I'm not sure if it's the best way, but I was able to query how many lines the buffer had and set the cursor of the buffer's window to the bottom.
When I want to quit Neovim, it asks me to save all these temporary buffers (which I don't want to do)
This is because the buffers are modified. Neovim by default doesn't want to make it easy to accidentally lose your work if you have active modifications. To get around that we can easily mark that it isn't modified!
Hope that helps.
I have an imbedded Tcl interpreter and want to redirect its stderr and stdout to a console widget in the application.
Using a chan push command for stderr seems to work (not much testing yet), like explained here:
TCL: Redirect output of proc to a file
I could have a file with the required tcl namespace definition, etc, and do a Tcl_Eval to source that script after creating an interp with Tcl_CreateInterp.
Can I do the same thing using Tcl C library calls instead of running the Tcl commands via a Tcl_Eval?
To implement a channel transformation in C, you first have to define a Tcl_ChannelType structure. Such a structure specifies a name for the transformation and pointers to functions for the different operations that may be done on a channel. Next, you implement the functions that perform those operations. The most important ones are inputProc and outputProc. You also have to implement a watchProc. The pointers for other operations can be set to NULL, if you don't need them.
For your example it may look something like:
static const Tcl_ChannelType colorChannelType = {
"color",
TCL_CHANNEL_VERSION_5,
NULL,
ColorTransformInput,
ColorTransformOutput,
NULL, /* seekProc */
NULL, /* setOptionProc */
NULL, /* getOptionProc */
ColorTransformWatch,
NULL, /* getHandleProc */
NULL, /* close2Proc */
NULL, /* blockModeProc */
NULL, /* flushProc */
NULL, /* handlerProc */
NULL, /* wideSeekProc */
NULL,
NULL
};
Then, when you want to push the transformation onto a channel:
chan = Tcl_StackChannel(interp, &colorChannelType, clientData,
Tcl_GetChannelMode(channel), channel);
For a complete example from the Tcl sources, see tclZlib.c
Not really an answer to my question, but maybe it will help someone to see what works by using a Tcl_Eval to show the tcl code that does the redirection.
proc redir_stdout {whichChan args} {
switch -- [lindex $args 0] {
initialize {
return {initialize write finalize}
}
write {
::HT_puts $whichChan [lindex $args 2]
}
finalize {
}
}
}
chan push stderr [list redir_stdout 1]
chan push stdout [list redir_stdout 2]
Both the chan push commands use the same proc, but pass an different identifier (1 or 2) to indicate whether stdout or stderr was the originator of the output.
HT_puts is an extension provided by the C code:
Tcl_CreateObjCommand(interp,"HT_puts",putsCmd,(ClientData) NULL,NULL);
int TclInterp::putsCmd(ClientData ,Tcl_Interp *,int objcnt,Tcl_Obj * CONST *objv)
{
if (objcnt != 3)
return TCL_ERROR;
int length;
int whichChan;
Tcl_GetIntFromObj(interp,objv[1],&whichChan);
//qDebug() << "Channel is $whichChan";
QString out =Tcl_GetStringFromObj(objv[2],&length);
QColor textColor;
if (whichChan==1)
textColor = QColor(Qt::red);
else
textColor = QColor(Qt::white);
console->putData(out.toUtf8(),textColor);
//qDebug() << out;
return TCL_OK;
}
Text forwarded from stderr gets colored red and text from stdout gets colored white.
And, as I mentioned above, each subsequent command that gets executed via Tcl_Eval needs to have the Tcl_Eval return value processed something like this:
if (rtn != TCL_OK)
{
QString output = Tcl_GetVar(interp, "errorInfo", TCL_GLOBAL_ONLY);
console->putData(output.toUtf8(),QColor(Qt::red));
//qDebug("Failed Tcl_Eval: %d \n%s\n", rtn,
}
To get what's normally printed to stderr by tclsh on a TCL_ERROR into the console (instead of the app's stderr).
I was planning to do the equivalent in C to eliminate the need to run Tcl code in the interpreter for the redirect. But, really there's no need for that.
The Tcl_Eval that does the redirection is done right after doing the Tcl_CreateInterp. Any subsequent Tcl_Evals using that interp will have stdout and stderr redirected to my application's console.
Besides, I'm having trouble understanding how to use Tcl_StackChannel and can't find an example I can follow.
Honestly, can't say that I completely understand the Tcl implementation. I made some assumptions on what gets passed to the proc used in the "chan push" command based on the referenced thread.
It looks like the proc is called with the list specified in the chan push command AND an args list. The first element of the args list is a name like "write" or "initialize". The third element looks like the string to be printed.
Still trying to find a definition of what's passed without having to dig into something like namespace ensemble.
So, it's likely that this Tcl code isn't the best implementation but it's working so far (with limited testing).
I am running a Perl script to control two other scripts. The user of the main program can call the two secondary scripts with the following line.
do 'Task_A.pl';
The script then runs Task_A.pl but I would like to find a way of then exiting Task_A.pl and return to the main program. If possible I would like to return to the function where I last called the secondary script. I am not sure as to what this is called but I appreciate any input for a possible solution.
This is the whole main program, not much to it at the moment.
my $selecion;
#Looping variables.
my $program_loop = 1;
while ($program_loop == 1)
{
print "Please choose one of the programs listed in the menu.\n";
#Program menu where the user chooses from the presented options.
print "[1] - Script A.\n";
print "[2] - Script B.\n";
print "[3] - Exit program.\n";
my $user_input = <>;
if ($user_input == 1) # <-- Scrip_A.pl
{
do 'Task_A.pl';
}
elsif ($user_input == 2) # <-- Scrip_B.pl
{
do 'Task_B.pl';
}
elsif ($user_input == 3) # <-- Exit Program
{
#The user can choose to exit from the menu.
print "The program will now exit.\n";
exit;
}
}
do does not start another process. If that's what you want, use "system()".
If you want do, then it's probably best to just put everything into a function in the file to be evaluated and call the function at the end of the file.
Use "return" to leave the function and return to next instruction after do.
I am working with mongo client. Sometimes the output of some commands I execute involve an enormous output, which mongo prints on screen. How can I avoid this?
There is a way to suppress output.
Using "var x = ...;" allows to hide output of expressions.
But there are other commands that harder to suppress like
Array.prototype.distinct = function() {
return [];
}
This produces printing of new defined function.
To suppress it you will need to write it in this way:
var suppressOutput = (
Array.prototype.distinct = function() {
return [];
}
);
Per the comment by #WiredPrairie, this solution worked for me:
Just set the return value to a local variable: var x=db.so.find(); and inspect it as needed.
I'm trying to write a very simple program to replace an existing executable. It should munge its arguments slightly and exec the original program with the new arguments. It's supposed to be invoked automatically and silently by a third-party library.
It runs fine, but it pops up a console window to show the output of the invoked program. I need that console window to not be there. I do not care about the program's output.
My original attempt was set up as a console application, so I thought I could fix this by writing a new Windows GUI app that did the same thing. But it still pops up the console. I assume that the original command is marked as a console application, and so Windows automatically gives it a console window to run in. I also tried replacing my original call to _exec() with a call to system(), just in case. No help.
Does anyone know how I can make this console window go away?
Here's my code:
int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
char* lpCmdLine,
int nCmdShow)
{
char *argString, *executable;
// argString and executable are retrieved here
std::vector< std::string > newArgs;
// newArgs gets set up with the intended arguments here
char const ** newArgsP = new char const*[newArgs.size() + 1];
for (unsigned int i = 0; i < newArgs.size(); ++i)
{
newArgsP[i] = newArgs[i].c_str();
}
newArgsP[newArgs.size()] = NULL;
int rv = _execv(executable, newArgsP);
if (rv)
{
return -1;
}
}
Use the CreateProcess function instead of execve. For the dwCreationFlags paramter pass the CREATE_NO_WINDOW flag. You will also need to pass the command line as a string as well.
e.g.
STARTUPINFO startInfo = {0};
PROCESS_INFORMATION procInfo;
TCHAR cmdline[] = _T("\"path\\to\\app.exe\" \"arg1\" \"arg2\"");
startInfo.cb = sizeof(startInfo);
if(CreateProcess(_T("path\\to\\app.exe"), cmdline, NULL, NULL, FALSE, CREATE_NO_WINDOW, NULL, NULL, &startInfo, &procInfo))
{
CloseHandle(procInfo.hProcess);
CloseHandle(procInfo.hThread);
}
Aha, I think I found the answer on MSDN, at least if I'm prepared to use .NET. (I don't think I'm really supposed to, but I'll ignore that for now.)
System::String^ command = gcnew System::String(executable);
System::Diagnostics::Process^ myProcess = gcnew Process;
myProcess->StartInfor->FileName = command;
myProcess->StartInfo->UseShellExecute = false; //1
myProcess->StartInfo->CreateNowindow = true; //2
myProcess->Start();
It's those two lines marked //1 and //2 that are important. Both need to be present.
I really don't understand what's going on here, but it seems to work.
You need to create a non-console application (i.e. a Windows GUI app). If all this app does is some processing of files or whatever, you won't need to have a WinMain, register any windows or have a message loop - just write your code as for a console app. Of course, you won't be able to use printf et al. And when you come to execute it, use the exec() family of functions, not system().