Running Firebird 2.5 as a service on a local 64-bit Windows 10 machine.
isql, qli and a bunch of the other tools run just fine.
However when I try an launch gfix, gbak and gstat the window barely opens before disappearing. It does this so quickly nothing is visible.
Any recommendations for dealing with this?
My actual goal at the moment is to change a firebird database from read-only to read-write. Which you can do using gfix http://www.firebirdsql.org/manual/gfix-dbmode.html
If there is some other method to change to read-write I'd happily use it.
The tools gfix, gbak and gstat are command line utilities. They expect certain command line options, and they print their output to the console. If you start them by double-clicking them in explorer, or executing them from the Run prompt, a console is opened, output is written (the usage information as you haven't specified the necessary command line options), and then it exits, closing the console immediately.
This means that if you want to run them and see the output, you need to execute them from the command prompt (cmd), or from a batch-file that has pause at the end.
The fact qli and isql work by opening them from explorer (or run) is because they are interactive tools, waiting for your input.
Related
My question is whether it is possible to edit the crontab of a WSL2-based instance of Ubuntu with my Windows VSCode that is connected via WSL remote SSH.
If I type export EDITOR=code inside my WSL instance and then crontab -e, I am able to see a /tmp/crontab.sygFAU file load inside my VSCode instance.
The problem is that once I make edits to this file, it will save the file to /tmp/crontab.sysFAU but it doesn't actually take the next step of replacing the the real crontab file in /var/spool/cron/crontabs.
So once I re-open the crontab, it will just show what I had previously, and not my saved edits.
It would be nice to know if this is not possible or if there are any alternative ways to run a GUI editor because using nano is a pain!
An interesting question that I haven't considered before, myself. Here's what's happening:
You set your editor to code
You crontab -e, which properly loads VSCode with the temporary crontab.
However, because this is a Windows GUI application, it returns control to the parent Linux application (crontab) immediately after starting VSCode. You can see the same result if you just start notepad.exe from your shell in WSL -- Once Notepad starts (rather than exits) control is returned to the shell.
If you switch back to your terminal at this point, you'll see that crontab detected that the editor that it launched exited (returned), and so it has already tried to copy the temporary file to the permanent location.
However, since the temporary files doesn't yet have any changes, crontab decides there's nothing to do.
Editing the file in VSCode and saving it has no effect, other than to leave a dangling /tmp/... file hanging around (since crontab isn't there to clean up).
So what's the solution? We need a way to launch a Windows GUI application and prevent it from returning control to crontab until you are done editing.
I originally thought something from this question might work, but the problem is that the actual command that launches the Windows process is embedded in a shell script, which you can see with less "$(which code)" (or code "$(which code)"), but it's probably not a great idea to edit this.
So the next-best thing I came up with is a simple "wrapper" script around the (already-a-wrapper) code command. Create ~/.local/bin/code_no_fork.sh (could be anywhere) with:
#!/usr/bin/env bash
code $* > /dev/null
echo Press Spacebar to continue
read -r -s -d ' '
Credit: This answer for the Spacebar approach
Then:
EDITOR=~/.local/bin/code_no_fork crontab -e
After you make your edits in VSCode, simply press Space to allow the script to continue/exit, at which point crontab will (assuming no errors were detected) install the new Crontab.
Alternatives
This is should typically only be a problem with Windows GUI applications, so the other possible avenue is to simply use any Linux editor that doesn't fork. If you want a GUI editor, that's entirely possible as long as you are running a WSL release that includes WSLg support (now available for Windows 10 and 11).
I won't offer any individual editor suggestions since that would get into "opinion" and "software recommendation" territory, which is off-topic here.
I have 1000 images, and thanks to ImageMagick I can retrieve a lot of information regarding an image by writing "identify -verbose [PATH OF IMAGE]" in the cmd.
I installed ImageMagick with 'legacy on' , to access individual tools rather than the monolithic version of the library.
If I write "identify -verbose C:\\temp\\cbirCorel10k\\1.jpg" in the command prompt it works perfectly, outputting data I need.
My problem is when I insert this code into PROGRAM of PostgreSQL like so :
copy manyline(txt)
from program 'identify -verbose C:\\temp\\cbirCorel10k\\1.jpg'
It gives me this error, and please note that I do have permissions on the image and parent folders to be accessed:
ERROR: program "identify -verbose C:\temp\cbirCorel10k\1.jpg"
failed SQL state: 38000 Detail: child process exited with exit code
1
I want that the output from that command line, is inputted into the table 'manyline' under column 'txt'.
Please note that the following code works well, but I want to make use of the PROGRAM function.
copy manyline(txt)
from 'C:\\temp\\something.txt'
The postgresql server needs permissions to run that program and read that file. it usually runs under username postgres (unless they've changed that recently). this is a "service user" and can be hard to find in the windows GUI; especially on "home" editions of windows. I can't say for sure if granting NETWORK SERVICE access is enough.
easiest solution is to use the psql command-line interface and do
\copy manyline(txt) from program 'identify -verbose C:\\temp\\cbirCorel10k\\1.jpg'
\copy is a psql built-in which runs the command (opens the file etc) as the current user, instead of asking the server to run it. this also works well where the server is not local.
I have a problem with DB2CLP environment variable, on Windows 7 64, IBM_client64_V97 (to be connected with DB2).
Every time when i try to DB2 in Windows command prompt window, I receive this error:
DB21061E Command line environment not initialized.
and per this document using just this step:
2. at the prompt enter these commands:
db2cmd -i -w db2clpsetcp
echo %DB2CLP%
I fix that error, and "db2" command opens Command Line Processor for DB2 Client.
But it lasts only until windows CMD is open. As soon as I close it and reopen, I have to repeat process.
My question (being absolute novice to DB2) is:
How should I make that change permanent and
How this happened at the first place as I installed and setup everything according to the manual (including adding local user to DB2USERS and DB2ADMINS) groups?
When DB2 client is installed, it should have installed a functional window to the command line processor. Check here:
Start / All Programs / IBM DB2 / DB2copy1/ Command Line Processor
Note that DB2copy1 is the default location for the first db2 instance. The name may be different if user select the non-default name.
Shortcut to the CLP can be copied on the desktop.
Regarding the typing "DB2 ..some command..." in windows command prompt which causes described error explanation is as follows:
That's because the normal DOS (or Windows) prompt doesn't
automatically run the setup script that enables the DB2 commands.
When the setup runs, it puts the DB2 items first in the PATH variable.
That could conflict with other tools that also want to be first on the
search list.
If you've got both the DOS (Windows) and DB2 command line prompts on
your desktop, right click them and select Properties. You'll notice
that the system (DOS) prompt runs cmd.exe.
The DB2 prompt runs DB2CMD.exe from the DB2 libraries. The DB2 script
then runs DB2SETCP.BAT and finally DB2.EXE. (All of the DB2
executables should be in C:\Program Files\IBM\SQLLIB\BIN.)
So there are differences in the two prompts. For you purposes, try
running DB2SETCP.BAT from the normal DOS prompt. That may be
sufficient for your needs.
For my purposes I always have the DOS and DB2 prompts on my desktop
and just select the one that I need.
I am debugging a windows process that crashes if the execution stops for even a few milliseconds. (I don't know how many exactly, but it is definitely less than the time taken by my reflexes to resume the process.)
I know I can launch a windbg session via the command prompt by typing in windbg -p PID which brings up the GUI. But can I then further pass it windbg commands via the command prompt, such as bm *foo!bar* ".frame;gc";g".
Because If I can pass it these commands I can write these down in a .bat file and just run it. There would at least be no delay due to entering (or even copy-pasting) the commands.
Use the -c parameter to pass them:
windbg -p PID -c "bm *foo!bar* .frame;gc;g"
According to the help (found by running windbg /?):
-c "command"
Specifies the initial debugger command to run at start-up. This command must be enclosed in quotation marks. Multiple commands can be separated with semicolons. (If you have a long command list, it may be easier to put them in a script and then use the -c option with the $<, $><, $><, $$>< (Run Script File) command.)
If you are starting a debugging client, this command must be intended for the debugging server. Client-specific commands, such as .lsrcpath, are not allowed.
You may need to play around with the quotes...
Edit: Based on this answer, you might be better off putting the commands into a script file to deal with the quotes:
script.txt (I think this is what you want):
bm *foo!bar* ".frame;gc"
g
Then in your batch file:
windbg -p PID -c "$<full_path_to_script_txt"
Am attempting to run installer using command line using -c option.
Command line execution appears like this:
E:\dev>MyApp_32.exe -c
E:\dev>This will install App on your computer.
OK [o, Enter], Cancel [c]
E:\dev> (showing the Windows command line is confusing to user)
Welcome .. (text of 2nd screen)
Typing "c" or "Cancel" doesn't work. It always takes enter key as input and proceeds to next screen.
Pressing enter transfers control back to windows's command shell, then back to installer. This looks confusing to user. It doesn't give a unified experience to user.
Is it possible to provide input via a silent file ? i.e. a text file with pre-selected inputs?
Am using 32 bit installer on Win 7 Professional x64 with Java 1.6 installed.
The problem is that the installer is a GUI application, it cannot take control of a WIndows terminal in this way. If you start it via
start /wait MyApp_32.exe -c
the command line prompts will not be displayed.
You can run set a response file with the -varfile argument, see the help for more information.