I'm building a lightweight version of the ncurses library. So far, it works pretty well with VT100-compatible terminals, but win32 console fails to recognise the \033 code as the beginning of an escape sequence:
# include <stdio.h>
# include "term.h"
int main(void) {
puts(BOLD COLOR(FG, RED) "Bold text" NOT_BOLD " is cool!" CLEAR);
return 0;
}
What needs to be done on the C code level, in order that the ANSI.SYS driver is loaded and the ANSI/VT100 escape sequences recognized?
[UPDATE] For latest Windows 10 please read useful contribution by #brainslugs83, just below in the comments to this answer.
While for versions before Windows 10 Anniversary Update:
ANSI.SYS has a restriction that it can run only in the context of the MS-DOS sub-system under Windows 95-Vista.
Microsoft KB101875 explains how to enable ANSI.SYS in a command window, but it does not apply to Windows NT. According to the article: we all love colors, modern versions of Windows do not have this nice ANSI support.
Instead, Microsoft created a lot of functions, but this is far from your need to operate ANSI/VT100 escape sequence.
For a more detailed explanation, see the Wikipedia article:
ANSI.SYS also works in NT-derived systems for 16-bit legacy programs executing under the NTVDM.
The Win32 console does not natively support ANSI escape sequences at all. Software such as Ansicon can however act as a wrapper around the standard Win32 console and add support for ANSI escape sequences.
So I think ANSICON by Jason Hood is your solution. It is written in C, supports 32-bit and 64-bit versions of Windows, and the source is available.
Also I found some other similar question or post which ultimately have been answered to use ANSICON:
How to load ANSI escape codes or get coloured file listing in WinXP cmd shell?
how to use ansi.sys in windows 7
How can I get cmd.exe to display ANSI color escape sequences?
ansi color in windows shells
enable ansi colors in windows command prompt
Starting from Windows 10 TH2 (v1511), conhost.exe and cmd.exe support ANSI and VT100 Escape Sequences out of the box (although they have to be enabled).
See my answer over at superuser for more details.
Base on #BrainSlugs83 you can activate on the current Windows 10 version via register, with this command line:
REG ADD HKCU\CONSOLE /f /v VirtualTerminalLevel /t REG_DWORD /d 1
For Python 2.7 the following script works for me fine with Windows 10 (v1607)
import os
print '\033[35m'+'color-test'+'\033[39m'+" test end"
os.system('') #enable VT100 Escape Sequence for WINDOWS 10 Ver. 1607
print '\033[35m'+'color-test'+'\033[39m'+" test end"
Result should be:
[35mcolor-test[39m test end
color-test test end
Starting from Windows 10, you can use ENABLE_VIRTUAL_TERMINAL_PROCESSING to enable ANSI escape sequences:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt638032(v=vs.85).aspx
If ANSICON is not acceptable since it requires you to install something on the system, a more lightweight solution that parses and translates the ANSI codes into the relevant Win32 API console functions such as SetConsoleTextAttribute.
https://github.com/mattn/ansicolor-w32.c
For coloring the cmd you need Windows.h and use SetConsoleTextAttribute() more details can be found in http://msdn.microsoft.com/en-us/library/windows/desktop/ms686047%28v=vs.85%29.aspx
In lastest win10, it can be done by SetConsoleMode(originMode | ENABLE_VIRTUAL_TERMINAL_PROCESSING). See https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#example
Maybe ANSICON can help u
Just download and extract files, depending on your windows os: 32bit or 64bit
Install it with: ansicon -i
I personally like clink. It not only processes ANSI codes, it also adds many other features so Windows Console behaves like bash (history, reverse history search, keyboard shortcuts, etc.):
The same line editing as Bash (from GNU's Readline library).
History persistence between sessions.
Context sensitive completion;
Executables (and aliases).
Directory commands.
Environment variables
Thirdparty tools; Git, Mercurial, SVN, Go, and P4.
New keyboard shortcuts;
Paste from clipboard (Ctrl-V).
Incremental history search (Ctrl-R/Ctrl-S).
Powerful completion (TAB).
Undo (Ctrl-Z).
Automatic "cd .." (Ctrl-PgUp).
Environment variable expansion (Ctrl-Alt-E).
(press Alt-H for many more...)
Scriptable completion with Lua.
Coloured and scriptable prompt.
Auto-answering of the "Terminate batch job?" prompt.
Ansi.sys (in the system32 folder) is an "MSDOS driver" provided as part of Windows XP, 2000, and earlier versions of NT. In 2000 and XP, it is located in the system32 folder (I don't remember the structure of earlier versions of NT). Programs that run in the DOS subsystem and use standard output can use ANSI.SYS just as they could running over MSDOS.
To load ansi.sys, you must use the device= or devicehigh= command in config, just as you would in MSDOS. On Windows NT 5 (2K & XP), each copy of the DOS subsystem can be given a separate config file in the pif/shortcut (use the "advanced" button), and there is a default file called CONFIG.NT (also in the system32 folder), which is used if the pif/shortcut does not specify a special config file.
When ansi.sys is loaded correctly, mem /d will report that it is loaded. On earlier versions of NT, you can and must load a proper DOS environment to load ansi.sys, and ansi art will work at the prompt. On Win 2K and XP, loading ansi.sys will have no effect on your "CMD prompt" because CMD is not a DOS program: it is a 32 bit Windows console program. For some reason that I do not understand, on WinXP, even if you load a fixed copy of command.com using "command.com /p", the command prompt will not be ansi enabled: perhaps when you do it that way it only emulates loading command.com?
In any case, when you use an actual DOS version of command.com, ansi is enabled after being loaded: you can demonstrate it's use with a bit of ansi art like this:
command /c type ansiart.ans
(here is an example: http://artscene.textfiles.com/ansi/artwork/beastie.ans)
CONFIG.NT (in the system32 folder) contains an example of the syntax for loading device drivers. You will need to be an Administrator to edit that default file, or you can make a copy of it.
On Win 2K and XP, the default "shortcut" for MSDOS is a .PIF file, not a .LNK file. If you create a .lnk file to CMD, you won't be able to set special config and autoexec files, it will use the default CONFIG.NT. If you want to use a special config file for just one DOS application, you can make a copy of the "MSDOS shortcut", or you can make a copy of "_default.pif", found in your Windows folder.
Had the same issue. I installed ConEmu and that one solved my problem.
I found this tool to be working for my end.
Microsoft Color Tool from GitHub
Unzip the compressed file then open CMD with Administration permission.
Go to the folder where you unzip the file in CMD.
Then execute this command "colortool -b scheme-name"
The scheme-name needs to be replaced with any of these options below:
campbell.ini
campbell-legacy.ini
cmd-legacy.ini
deuternopia.itermcolors
OneHalfDark.itermcolors
OneHalfLight.itermcolors
solarized_dark.itermcolors
solarized_light.itermcolors
In my case, the command would be like this "colortool -b solarized_dark.itermcolors"
Click right on the console window and select Properties.
You don't need to change any value just click "OK" to save the setting. (You will notice that your font already contains colors).
Console Property
Then restart your cmd or powerShell.
The ANSI color should be enabled and working with the color scheme you chose before.
Somehow in Windows you just need to call any shell command first, rather call the system function. Just in start of your main method put system("");, and don't forget to include stdlib.h.
I noticed this when I looked at some of my old programs that also used ANSI codes to understand why they work, but my new code is not
I know that when creating a .desktop file, one can set the metadata::trusted as true and false, in order to be able to launch the icon as an executable.
What is intriguing me however is the fact that:
When right-clicking on the .desktop file and "Allow launching" apparently the only thing it does is to set the metadata::trusted to true. The icon, however, changes, as expected, instantly to the icon described in the .desktop file Icon=.
However when setting the metadata::trusted to either false or true via command-line the icon doesn't seem to change its behavior
$ gio set android-studio.desktop metadata::trusted false
Once I refresh the Desktop manually (Alt + F2 >> restart) the environment refreshes and the icon turns to be executable again, BUT the whole environment is restarted.
So, What does exactly "Allow/Disallow launching" does after setting the metadata::trusted? How does it refresh the metadata in the .desktop itself without refreshing the whole Desktop?
Your question is exactly the same as what I'm looking for.
On Ubuntu 18.04 (GNOME 3.28):
dbus-launch gio set file.desktop "metadata::trusted" yes
and (although this is not quite what you need)
killall nautilus-desktop && nautilus-desktop & disown
Ubuntu 20.04 (GNOME 3.36):
dbus-launch gio set file.desktop "metadata::trusted" true
but no nautilus-desktop...
dbus-send --type=method_call --print-reply --dest=org.gnome.Shell /org/gnome/Shell org.gnome.Shell.Eval string:'global.reexec_self()'
or something like systemd*...
Look at this code:
https://gitlab.gnome.org/GNOME/nautilus/commit/1630f5348
and here search "trusted":
https://download.gnome.org/core/3.36/3.36.2/sources/
nautilus-3.36.2/src/nautilus-file-operations.c
nautilus-3.36.2/src/nautilus-mime-actions.c
It may turns out to be simpler.
From desktop-file-utils.
man desktop-file-install
For example:
desktop-file-install --mode=0755 --dir=$HOME/Desktop /path/to/source/file.desktop
Quiet interesting, I've used combination of the two previous answers in order to "Allow Launching" .desktop file located at my desktop within Kali Linux 2022 with GNOME Shell:
desktop-file-install --mode=0755 --dir=$HOME/Desktop ~/Desktop/Telegram.desktop
dbus-launch gio set ~/Desktop/Telegram.desktop "metadata::trusted" true
Note the order of the execution of the commands is important!
Here is similar topic at Ask Ubuntu: .desktop files - Allow launching - set this via CLI.
Also for these who are interested in here is How to install the latest version Telegram for Desktop via CLI which was the reason to searching for the current topic.
I'm currently developing an application with QT 4.8 with a "Launch on login" option. My main problem currently is that I can't seem to find a proper way to make the program launch itself after login on Linux (Fedora 20 in my case).
My program should be able to run in the background without stopping fedora to launch.
I would also like to avoid having to ask for any sort of admin privilege since my application doesn't require any (except maybe for this option).
Finally found out about "home/.config/autostart/.desktop".
I'll have to create autostart if it's not created but from there I can chose to make or delete the file depending on what my user decided to do.
The .desktop file have to follow a particular syntax (which is not a problem for me)
[Desktop Entry]
Type=Application
Exec=</path/to/binary or command to execute>
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=<Name_to_be_displayed>
Comment=<optional comment>
In my case, I can just remove the "comment" line since just the name of the application should be enough for the user to recognize it.
You can Either keep your executable in side /etc/rc.d/rs or inside /etc/init.d folder, so that it can automatically start once device is up.
Hope this Helps.
Each user has a .bashrc file located in their home directory, you could append a command to run your application to the end of that.
That will run when only that user logs in (I think either with graphical or terminal session)
To run for all users, look at creating a systemd service if you dare, or append a line to the end of /etc/rc.local. You'll need to be root for that though.
EDIT: Don't forget to put an ampersand at the end of the command to run in background.
My application downloads updates from a server. After downloading it runs updater.exe (which is set to run with administrative rights) so it can copy the update foo.exe over my application. Since you can't replace the file while it runs the helper application is necessary.
I am making the following system call to run it:
result=_execl(updaterexe,updaterstr,updateFilestr,exeFilestr,exeFilestr,NULL);
The parameters contained:
c:\program files\foo\updater.exe "c:\program files\foo\updater.exe" "c:\downloads\newfoo.exe" ""c:\program files\foo\foo.exe"
Under vista this works as expected.
Under windows 7 it returns error code 22 which is invalid parameter. I have also tried quoting the first parameter to no avail. Suspecting that maybe the old _execl was not supported on windows 7 I tried adjusting all the parameters and calling _wexecl but with no change in behaviour.
Can anyone suggest a correction to the call I'm making or suggest a different system call that will work consistently between versions of windows?
There are plenty of other alternatives, any of which would work from Windows 95 up:
CreateProcess() // Recommended Win32 API
ShellExecute ()
system ()
I'm using the Win32 function GetEnvironmentVariable to retrieve the value of a variable that I just created. I'm running Windows XP and VC++ 2005. If I run the program from within Visual Studio, it can't find the new variable. If I run it from a command-prompt, it does. I restarted VC++ but same result. I even restarted all instances of Visual Studio but still the same problem. It might get resolved if I reboot the PC but I'm curious why this is so. Here's the code that I'm using:
#define BUFSIZE 4096
#define VARNAME TEXT("MY_ENV_NAME")
int _tmain(int argc, _TCHAR* argv[])
{
TCHAR chNewEnv[BUFSIZE];
DWORD dwEnv = ::GetEnvironmentVariable(VARNAME, chNewEnv, BUFSIZE);
if (dwEnv == 0)
{
DWORD dwErr = GetLastError();
if(dwErr == ERROR_ENVVAR_NOT_FOUND)
{
printf("Environment variable does not exist.\n");
return -1;
}
}
else
{
printf(chNewEnv);
}
return 0;
}
If I replace MY_ENV_NAME with something that must exist, such as TEMP, it works as expected. Any ideas? Thanks.
Expanding on what Anders and Martin said, environment variables are one thing that is inherited when starting an application. The new program basically gets a copy of the environment at the time it was started. When debugging, your exe is generally started by Visual Studio, so your application will have the same environment as Visual Studio. Visual Studio, is generally started by explorer. If you change the environment variables by going to System Properties->Advanced->Envronment Variables then you will have to restart Visual Studio to see the changes.
If you need to see the envronment variables that Visual Studio is seeing you can (at least for VS2005/2008) go to Tools...->options...->Projects and Solutions->VC++ Project Settings and set Show Environment in Log to 'Yes.' This will print out all the environment variables to the build log (ctrl+click on the link in your build output). You have to build to get this info, but this is the best way I know of seeing the VS environment.
If you really need to change environment variables then run and are having a hard time debugging, you can build your debug exe and have a call to DebugBreak() somewhere near where you want to start debugging from. Then you can set your environment how you want, start the exe from explorer or the command prompt. Then (assuming you have JIT debugging enabled) you will get a popup when your code gets to the DebugBreak() call and you can attach to it with VS and debug normally from there.
Make sure you restart the application before you can read the environment variable. The same happens if you have a console window open and change the environment variables on My Computer, these are not noted in any existing console windows. You need to restart them to get a copy of the new environment variables.
It all depends on how you set the environment variable:
If you ran set MY_ENV_NAME=val in a command prompt, then you have set MY_ENV_NAME for that instance of cmd.exe and any child processes it executes in the future. The environment of existing child processes is not modified.
In this case, exiting the Visual Studio IDE and starting it from the command line (not Explorer) should cause it and its child processes to see the new environment variable.
If you used the System or Users control panel or the setx command to set MY_ENV_NAME, then you have set MY_ENV_NAME persistently, and it will be set for all processes after you reboot your computer. In addition, you may find that some processes, such as Explorer, pick up the environment variable change immediately.
This works by storing the new environment variable in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment or HKEY_CURRENT_USER\Environment, depending on whether you chose to set a system environment variable or a per-user environment variable. Existing processes are notified that there was an environment variable change by broadcasting the WM_SETTINGCHANGE message with lParam=="Environment". This message causes them to re-read the persistent environment variables from the registry if they know how. KB104011 has more details.
As a result, if you use the System or Users control panel to set a new environment variable, exiting the Visual Studio IDE and starting it again from Explorer (not a command prompt) should cause it and its child processes to see the new environment variable.
Thanks for all the responses. As I mentioned in my question, I tried restarting everything, short of rebooting the PC. It turns out that because my environment variable was a SYSTEM variable, VS doesn't recognize it without rebooting the PC. When I moved the env variable from SYSTEM to USER and restarted VS, it worked fine.