I'm not sure if this is possible, but hear me out.
I want to display another language (Russian) in the command prompt window. Is it possible?
I type it all in a .txt, save and then make it a .bat
Example:
#echo off
echo Привет <-- (Russian for "Hello")
pause
But with that, I get weird characters. Can I include the Cyrillic text into it, or is it only limited to English characters?
EDIT:
Tried to use chcp. When using straight in the cmd window, going to chcp 866 and chcp 1251 makes the promt show the characters and it works. But when using just a .bat file, I get weird characters. But not like O's and n's with wiggly lines on top, characters like equals signs and 90 degree angles. I used the code above and tried adding chcp 866/1251 at the top. Still doesn't work. Could it be the problem with making the file?
You must set it to utf-8:
chcp 65001
Related
ASCII character code 0x07 is a beep character.
Opening CMD and clicking ALT + 007 yields :
And when I click ENTER - I hear a beep. This is fine.
I've searched how to add a beep in the end of a batch file, and I found that this is the solution : (I'm pasting it as an image becuase SO doesn't show the round bullet after editing) :
This does work and does make a sound. When examined with a HEX viewer (with beyond compare) on ECHO, the round bullet is:
But if I manually add ALT+7 to the document , I see this:
Which is a 95 as a hex - and it's not a Beep. In addition, I went to the working batch file and added a new line with my ALT+7 :
But looking via HEX viewer :
Question:
I'm a bit confused. Clicking Alt+65 does yields A everywhere.
So why does the beep different and doesn't work when saved in Windows GUI?
In the console, if I click ALT+007 I get ^G (it does beep), but when I click ALT+7 I get the circle, which is not a beep:
Here are both:
Another interesting observation via notepad++ :
I think it's related to encoding, etc, but I don't understand the inconsistency.
I have a workaround to suggest. Put this in your script:
forfiles /p "%~dp0" /m "%~nx0" /c "cmd /c echo 0x07"
For every file in your script's directory matching your script's filename (e.g. 1 time), it will echo ASCII character 7, and will make noise. From the forfiles /? documentation:
To include special characters in the command line, use the hexadecimal code for the character in 0xHH format (ex. 0x09 for tab). Internal CMD.exe commands should be preceded with "cmd /c".
forfiles is a handy utility to abuse whenever you need a non-printable or extended character.
As for my speculation for why Alt+007 doesn't behave as expected, I believe the console works on a different codepage from windowed applications (console = 437, windowed = 1252 for en-US, IIRC). I've struggled with this issue as well for reasons, ultimately resorting to hard coding the symbols used for console characters 1 through 31 in that JavaScript project.
This is not really an answer, but it would be too large for a comment.
The "manually adding ALT+7 to the document" part produced strange results which it should not have produced. The result should have been a single 0x07 character. It may be that your editor did something funny when you pressed ALT+7.
The problem with this kind of troubleshooting is that the tools you are working with have complex behavior that distorts the experiment. The tools also have strange modes and strange states. For example, what is the encoding of your console subsystem?
I tried this: copy con x.bat typed echo followed by Alt+7 and then Ctrl+Z and got a beeping batch file. The character looked like a bullet.
Then I tried with Alt+007 and I also got a beeping batch file, but the character was ^G now.
At the C:\> prompt, I typed echo followed by Alt+7, a bullet was also produced, but there was no beep. But an Alt+007, looking like a ^G did produce a beep. Go figure.
I would say ignore the inconsistencies that occur when you are trying to input a control character, because there is a lot of software involved in doing so which is beyond your control and apparently works in mysterious ways. (I know, not an answer.)
To beep in a cmd file :
Solution 1
C:\>rundll32 user32.dll,MessageBeep -1
Solution 2
C:\>echo ^G>beep.txt
C:\>type beep.txt
NB :
^G is obtained by pressing Ctrl+G and you can see the character by editing beep.txt
I used vim to open a file event.txt and show me some search results. This worked fine, but since I did a change in the _vimrc it displays the file content with #-signs so that it is unreadable. See image below.
What I did change in _vimrc was
set fileencoding=utf-8
but I commented it. So it should not affect vim.
"set fileencoding=utf-8
The file is still displayed unreadable. With other editors I can open the file and view it normally. I had this behaviour some time ago, but I vanished somehow. I can't remember.
The event.txt file is the windows event file which I generate through the powershell:
get-eventlog -logname system > event.txt
Something tells me it's not the change in the _vimrc and perhaps something else, but this is the last change I remeber I did and after this it did not work.
How can I view in vim the windows event file event.txt normaly? Without #-signs.
That ÿþ at the beginning is a byte order mark (BOM), typical for Windows Unicode text. The ^# is Vim's representation of a NUL value, and it (roughly) appears as every second character. So, you have a (mostly) ASCII-text file, encoded in UCS-2 little endian: each character is represented by two bytes (16 bit), the lower one comes first.
You can open that file with
:edit ++enc=ucs2-le event.txt
But it's better to set up Vim correctly so that it automatically detects it. Since you're using GVIM on Windows, I would recommend to put
:set encoding=utf-8
at the start of your ~/.vimrc. This will automatically set your 'fileencodings' to a good default of ucs-bom,utf-8,default,latin1. Note the first element; that should help detect the file.
Do not set 'fileencoding' in your ~/.vimrc! That is a buffer-local setting, and it will be automatically set by Vim on opening of the file. The 'fileencodings' (note the plural) is the right option to influence the detection.
I need to modify the way the CMD shows the path, whether it's in a batch file or not.
For example:
~/Users/MyName/Desktop
instead of:
C:\Users\MyName\Desktop
It would also be appreciated if somene could tell me how to use colours in CMD in the following way:
echo /color1Blah/color2Blah
This takes me back to the days when everyone knew and used DOS!
There is a environment variable that controls how the prompt is displayed in the command window.
PROMPT=$P$G
You can kind of accomplish what you want, but with limitations. For instance, if you go to a command window and type:
C:\>prompt ~$P[space] (don't type the C:\> and [space] is an actual space), your prompt will change to:
~c:\[space]
You can type prompt /? to see all of the available options. Once you have found a combination that you like, edit the environment variable and it will be set for all future command windows. The biggest limitation is that you cannot change the backslashes to forward slashes.
As for colors, type color /? from the command line. You can set the entire background and foreground colors, but not individual elements on the screen. That is unless you can get a copy Ansi.sys and get Windows to load it when you open a Command Window. Here are a couple of cool links to sites that use color in the PROMPT.
http://www.robvanderwoude.com/ansi.php
http://www.robvanderwoude.com/prompt.php
I Googled ansi.sys windows 7 and found a few people that said they got it working (like here). I don't have Ansi.sys anywhere to give it a try.
The first path is a Linux path the second is a windows path - never the two shall meet.
I have a random problem which I personally find quite irritating. I use the terminal alot and have installed a theme and even toyed around with what is displayed on the prompt. However if I write a particularly line of text it does not start a new line in the terminal instead it will begin overwriting what is displayed on the screen in the current terminal line. I wondered if anyone knew a way to solve this so that it does show a new line and all input would be visible.
PS1 value
export PS1="\r\n\e[1;32mdave:\w $\e[0;37m "
Well, thanks to the post by #Joni, I believe the solution is:
PS1="\r\n\[\e[1;32m\]dave:\w $\[\e[0;37m\] "
That is, here the color codes \e[1;32m and \e[0;37m are enclosed within \[ and \], as #Joni suggested they should be.
Non printing characters, like escape codes for color, have to be surrounded with \[ and \] so that bash knows to exclude them when calculating the length of the line.
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html
My question is related to this topic How to copy and paste code without rich text formatting? except its from the opposite viewpoint: I'm creating a document from PowerPoint in which I have code snippets in text boxes. I want to make the document as simple as possible by making the code snippet text boxes easy to copy and paste the code into a terminal to run without editing anything. However, the way I have it right now is that when I copy and paste it keeps the formatting and I have to go though letter by letter to erase the end of line symbols. How should I format this in PowerPoint?
You can get rid of most formatting by copy/pasting from PPT to Notepad and then copy/pasting from there to your terminal program, or if the latter has a Paste Special command, you should be able to paste as plain text, which'd get rid of formatting.
Line/Paragraph breaks are another matter. If the end of line symbols are the only formatting problem when you've pasted the text into a terminal (emulator program, I assume), it sounds as though the terminal's using CR or LF as a line ending, whereas PPT's using CR/LF pairs. It might only be necessary to reconfigure the terminal software to use CR/LF.
It's worth a look at this page on my site, where I explain what line and paragraph ending characters are used by different versions of PowerPoint in different situations.
Paragraph endings and line breaks
http://www.pptfaq.com/FAQ00992_Paragraph_endings_and_line_breaks.htm
Sorry, my mistake was not realizing that PowerPoint auto formats hyphens and quotation marks to make them stylized, and the terminal was not recognizing the symbols. All I did was type in a quotation mark/hyphen then copying that before I pressed the space bar after it to save the original formatting.