I'm working on an embedded linux system; my console is a serial port and there is a VGA video output at /dev/tty0.
I am trying to use the 'dialog' (1) utility to display menu-like displays on the VGA screen.
I can get dialog output on the console:
dialog --inputbox "Hello Dialog World" 10 30
and I can get something similar on the VGA screen by redirection:
dialog --inputbox "Hello Dialog World" 10 30 >/dev/tty0
But I want to use the '--output-fd' parameter to dialog to achieve a similar result and I can't get it to work.
I've tried things in a bash script like:
exec 4>/dev/tty0
dialog --output-fd 4 --inputbox "Hello Dialog World" 10 30
exec 4>&-
but this seems to write to the console as previously.
I seem to be misunderstanding the operation of the --output-fd parameter - can anyone help?
(in actual fact, I want to use the python-dialog wrapper for dialog; but I need to understand how to use the underlying dialog utility before I take the next step)
Quote from the manual page:
Some widgets, e.g., checklist, will write text to dialog’s output.
Normally that is the standard error, but there are options for
changing this: "--out-put-fd", "--stderr" and "--stdout".
This means that the --output-fd option does not specify a file descriptor for any output but only for the data generated by some widgets.
Related
I have a LiveCode app standalone that needs to know if there is a job waiting in the MacOS print queue before printing. If app user 1 prints the 2 page report and just one page prints (out of paper) then user 2 comes along and prints the report, the first page out is user 1's report and this is causing mixups. I would like to check the MacOS print queue and prevent printing if there is a job already waiting.
It's not something I've ever needed to do, but I suspect that this capability is not included in LiveCode natively. Instead your best bet will probably be to use LiveCode's shell() function to run a unix terminal command. For instance, lpstat is a command line utility that allows you to query various things about printers connected to your Mac. The following command, run in the MacOS terminal, shows which printers are available and their current status.
lpstat -p
In LiveCode you use the shell() function to call this command line utility, like so:
put shell("lpstat -p") into tPrinterStatus
To find out more about lpstat, open the Terminal and look up the man page:
man lpstat
Lots of options for that utility will appear. There should be one that gives you the information you need.
I'm a Debian Stretch user coming from Windows. In Windows with the launchy app (also available for Linux), I had a method of entering text into launchy that was then appended to the end of a .txt or .md file.
To do this in Windows, I created a file called note.bat that contained the following:
echo %*>>"C:\collectednotes.md"
I'd make launchy aware of note.bat by adding its containing folder to “Launchy” → “Settings” → “Catalog” and adding filetype *.bat.
From there, I'd launch launchy, type note, hit Tab, enter some text, hit Enter, and then the text would be added to the end of collectednotes.md.
A mostly working process is detailed in my answer below. I'll give the green checkmark answer to anyone that can adjust this process (via note.sh and/or launchy plugin setup detailed below) to appropriately handle all special characters.
This may contain the solution to this question:
Which characters need to be escaped in Bash? How do we know it?
Solved (almost). I'm keeping this question unanswered and will give to whoever completes the remaining ~5%. Steps to get the 95% solution with xfce4-terminal version 0.8.3-1:
Install launchy and launchy-plugins (both are version 2.5-4 for me):
apt-get install launchy
apt-get install launchy-plugins
Open terminal to default location of ~/ and create collectednotes.md:
echo "# Launchy Notes Collected Here" > collectednotes.md
Create note.sh shell script:
echo '#!/bin/sh' > note.sh
Create shell script line 2:
echo ALL_ARGUMENTS='"$#"' >> note.sh
Create shell script line 3:
echo 'echo "$ALL_ARGUMENTS" >> ~/collectednotes.md' >> note.sh
If you open note.sh, it will look like:
#!/bin/sh
ALL_ARGUMENTS="$#"
echo "$ALL_ARGUMENTS" >> ~/collectednotes.md
Make note.sh executable:
chmod +x note.sh
Launch launchy and click the gear icon in upper right for settings. If consistency with launchy for Windows is desired, set launchy Hotkey to Alt+Space. If you receive a keyboard shortcut conflict message as I do on Debian with Xfce, first go to Settings, Window Manager, Keyboard tab, and clear Alt+Space as the shortcut for Window operations menu.
Next in launchy settings, go to Plugins tab and enable the plugin Runner. Click the + button and create a new Runner custom command as follows:
- Name: note
- Program: /home/YOURUSERNAMEHERE/note.sh (launchy does not like Program path of ~/note.sh, so a specific path with username is required)
- Arguments: '$$'
Click the Catalog tab and hit Rescan Catalog just in case. Hit OK to close launchy settings.
Now let's test it.
- launch launchy with Alt+Space or your hotkey
- type note (You may have to wait 10 second or so on first run. You'll know things are as expected when you see the text "note" with a orange/yellow icon containing silhouette of a person.)
- hit Tab
- enter some text (no need for single or double quotes or escapes), e.g.: Remember to donate at least $3 to Josh at Launchy https://www.launchy.net/donate.php
- hit Enter
Now open collectednotes.md to confirm the text was captured.
The remaining issues seem to be dealing with single quotes and double quotes. For example, consider the following note:
I don't know what I'd do without Launchy.
Which results in the following in collectednotes.md:
I dont know what Id do without Launchy.
Or:
Would David Allen like universal text capture from anywhere in Linux? My bet is "yes!"
Results in the following in collectednotes.md:
Would David Allen like universal text capture from anywhere in Linux? My bet is \yes!\
Single quoting and/or double quoting the input to launchy doesn't solve it. Note the launchy Runner custom plugin construction component of '$$' is a piece of this puzzle.
I'll give the answer to anyone that can adjust this process (via note.sh and/or launchy plugin setup) to appropriately handle all special characters. Maybe this would add proper escapes to user input with something like gsub.
The rationale for being exacting regarding proper character handling is that this process is useful for copying and logging random chunks of text from web pages, but if common characters like single quotes are not handled as expected, confidence in the system is much reduced.
I found out about Dialogs, so I'm updating menus today. So far, so good.
I came to one where I need to collect a user's input.
I have
dialog --title " INPUT FILE NAME: " --inputbox "$(ls)" 30 40 2> answer
This will send the users input to a file named "answer"
I have tried
dialog --title " INPUT FILE NAME: " --inputbox "$(ls)" 30 40 2> $answer
but that doesnt seem to do anything.
I tried
answer=$(dialog --title " INPUT FILE NAME: " --inputbox "$(ls)" 30 40 2)
but there is some kind of error.
The manual page (for dialog) tells the story:
Some widgets, e.g., checklist, will write text to dialog's output.
Normally that is the standard error, but there are options for changing
this: "--output-fd", "--stderr" and "--stdout". No text is written if
the Cancel button (or ESC) is pressed; dialog exits immediately in that.
The reason dialog uses the standard error by default for its output is that it uses the curses/ncurses library, which normally prints its output (for the screen updates) to the standard output. To change dialog's behavior (and write to the standard output), use the "--stdout" option.
Interestingly (though it may appear an obvious problem to solve because it complicates scripting), the Xdialog program implemented this option first; it seemed a Good Thing to add to dialog (see changelog).
Done
dialog --title " INPUT FILE NAME: " --inputbox "$(ls )" 30 40 2>answer
ans=$(cat answer)
rm answer
I am building a interactive bash script and I have been using whiptail for input and message boxes. However the infoboxes will not always work. (Works on my active server but not on my VM. Same Ubuntu 14.04 accessed with Putty in windows)
I am trying to switch to dialog but the code I was using with whiptail to output to a variable rather than a file does not seem to work in dialog.
UNAME=$(whiptail--inputbox "Enter the user you want your scripts to run as. (Case sensitive, Must exist)" 10 50 --title "System Username" 3>&1 1>&2 2>&3)
I tried changing whiptail to dialog and I get a box and can enter and submit data but then the variable is not set. I got this from another forum and there was no real description of whats actually happening here. All I know is it sets the variable with the input data rather than what is normally output to stderr.
dialog appears to be sensitive to option ordering. Put the --title option before the --inputbox option and it should work (at least it does here).
I have an linux app that uses cups for printing, but I've noticed that if I print and then quit my app right away my printout never appears. So I assume that my app has to wait for it to actually come out of the printer before quitting, so does anyone know how to tell when it's finished printing??
I'm using libcups to print a postscript file that my app generates. So I use the command to print the file and it then returns back to my app. So my app thinks that the document is off to the printer queue when I guess it has not made it there yet. So rather than have all my users have to look on the screen for the printer icon in the system tray I would rather have a solution in code, so if they try and quit before it has really been sent off I can alert them to the fact. Also the file I generate is a temporary file so it would be nice to know when it is finished with so I can delete it.
As soon as your CUPS web interface (localhost:631) or some other thing to look at what CUPS sees shows you that CUPS received the job, you can quit the application.
How about using a print spool service like lpr & lpq?
You certainly do not need to wait till the paper is out of the printer. However, you need to wait until your temporary file is fully received by cupsd in its spooling aerea (usually /var/spool/cups/).
If you printed on the commandline (using one of the CUPS lp or lpr commands) you'd know the job is underway if the shell prompt returns (the command will even report the CUPS job ID for the job sent), and if the exit code ($?) is 0.
You do not indicate which part of libcups and which function call you are using to achieve what you want. If I'd have to do this, I'd use the IPP function cupsSendRequest and then cupsGetResponse to know the result.
Your app likely hadn't finished printing yet when you quit it. If you're using evince to print a PDF or other document, this is a known bug--there is no visual confirmation that the printing operation is underway. If the print job has been submitted, a printer icon will appear in your system tray until the actual printing has finished. You can click on the printer icon in the system tray and see what jobs are currently running and pending.