open OUT, ">output.txt";
print OUT "Hello\nWorld";
When I run the above perl code in a Unix system and then transfer output.txt to Windows and open it in Notepad it shows as:
HelloWorld
What do I need to do to get the newlines displaying properly in Windows?
Text file line endings are platform-specific. If you're creating a file intended for the Windows platform then you should use
open OUT, '>:crlf', 'output.txt' or die $!;
Then you can just
print OUT "Hello\nworld!\n";
as normal
The :crlf PerlIO layer is the default for Perl executables built for Windows, so you don't need to add it to code that will create files for its intended platform. For portable software you can check the host system by examining the built-in variable $^O
Windows uses carriage-return + linefeed:
print OUT "Hello\r\nWorld";
I wrote the File::Edit::Portable module that eliminates these problems. Although you can use it to write (along with many other things), you only need the read() functionality in this case.
Install the module, and at the top of your script, add:
use File::Edit::Portable;
When opening/reading the file, you can just do:
my $rw = File::Edit::Portable->new;
my $fh = $rw->read('file.txt');
No matter what the line endings are or what platform you're on, it does all of the cross-platform work in the background so you don't have to. That way, you can open the file on any system, regardless of what line endings you've decided to use, and it just works.
Newline handling is editor specific (there are a number of answers that claim it is OS specific, but that is, in real life, not true in general). However, it is true that on DOSish systems, longstanding convention is to use CRLF to indicate EOL (see also Why is fwrite writing more than I tell it to?)
If you try to open this file in any other editor than Notepad, you will notice that the text is properly displayed on two lines, with an indicator in a status bar or some other place that the file is opened in Unix mode or LF mode.
Unless you intend your file solely for viewing with Notepad, you don't have anything to worry about. Every other tool on Windows will deal fine with it.
However, Notepad does expect a CRLF sequence to mark the end of each line. If you do want to cater for it, then you can just output "\r\n" as #kizeloo suggests. I do prefer to use output layers when they are necessary.
Note that if you try to view such a file using an editor that requires a single LF to signify EOL, you may see ^Ms or other characters denoting the CR.
Related
I am currently trying to get an executable running in memory. Because it is high likely that someone will ask later: Yes, it will be used for malicious software in order to hide it from AV. It is only for educational purposes, in specific for a school project (will be part of my graduation).
However the question concerns something else. I found a really good source at Github: https://github.com/aaaddress1/RunPE-In-Memory, which works perfectly for my uses (I already changed it for my purposes etc), except for the trojan I want to run. I tried it with several, e.g Darkcomet or Darktrack (It needs to be something old what is already well known to demonstrate how you could reuse them). I thought because Darkcomet it coded in Delphi (which outputs a native?), it would work like any other EXE-File (Like the ones provided at Github), but it just does not start. In Darkcomet there is also an option for making the malicious server file noticeable, so it is safe that I did not fail at any port-forwarding stuff.
My first intention then was to open the EXE in a text editor and look if it is even the same architecture. I can find "PE L" in both binaries, so as far as I know it is both 32bit. A thing what seemed strange to me were the two lines
"This program cannot be run in DOS mode." for the compiled runPE loader
and
"This program must be run under Win32" for the trojan executable.
Furthermore the two Binaries differ in the first chars: MZ and MZP.
After opening up more binaries and testing them, I came to the conclusion that the ones with "This program must be run under Win32" do not work.
As far as i know and also googled, there are DOS and Windows executables. But if there are only these two types, why is there a difference?
"must be run under Win32" == "cannot be run in DOS mode." in my opinion.
I also looked up those two terms , but I only get Threads about people who try to run these Windows-PEs in DOSBox or similar things.
So, my actual two quesions are:
-What is the difference between "This program must be run under Win32"(Type1) and "This program cannot be run in DOS mode."(Type2)
-Why does it not work if I want to push a (Type1)program into the Memory with the (Type2)RunPe-InMemory executable which I made from the Github repository.
What is the difference between ... (Type1) and ... (Type2)
Nothing:
A "PE" executable consists of some MS-DOS EXE file followed by a 32- or 64-bit part.
If you start the "PE" executable under MS-DOS (or any compatible operating system), DOS will ignore the 32- or 64-bit part and execute the MS-DOS EXE file at the start of the "PE" executable file.
A few programs are written in a way that the DOS EXE file at the start of the PE file is doing the same as the Windows part, so you can use the same EXE file both under DOS and Windows.
However, in most cases the DOS part only prints some error message saying that the program cannot be started under MS-DOS.
What you see here are two different MS-DOS programs at the start of the PE EXE files; one program prints the error message "This program must be run under Win32", the other one prints "This program cannot be run in DOS mode."
Furthermore the two Binaries differ in the first chars: MZ and MZP
This is also not a difference:
The third byte of MS-DOS files is one of many bytes describing the length of an MS-DOS program. Because you have different MS-DOS programs, they also have different lengths.
In one case the byte has the value 80, which is shown as "P" in a text editor.
In the other case the byte might have the value 10 (as an example), which is not shown as character in a text editor.
Why does the runPE not work with a specific type of executables?
Not having seen the trojan, I cannot answer this.
However, I have seen many trojans which do not use a correct "PE" file format.
(However, in these cases the "errors" were after the "PE L", not in the "MZ"-part.)
In Ruby on Windows 7, how do you open a program's source file from the command line?
Example:
def dev_mode
if ARGV[0] == '--dev-mode'
system('open test.rb')
end
end
Is it possible to open a program using the default editor of the user's computer? Such as opening it in notepad (if the user doesn't have an editor) or the editor the user uses for source files?
The canonical way to open a file with the associated program is different from one operating system (or shell) to another. Here are 4 examples that will work on the specified OSes:
Opening the File
Windows
Use the standard command shell start, available beginning with Windows 95:
system %{cmd /c "start #{file_to_open}"}
Mac OS X
Use the standard open command:
system %{open "#{file_to_open}"}
Linux/Unix Gnome
Use the Gnome utility gnome-open:
system %{gnome-open "#{file_to_open}"}
Linux/Unix
Use the xdg-open utility:
system %{xdg-open "#{file_to_open}"}
Associated Programs
Detecting the associated program for a file type can be a fairly tall order on any one system. For instance, with Windows, you have to inspect the registry, whereas with Mac OS X you have to read the right plist values; Linux is a whole other world, altogether.
You're likely better off simply requiring the user to have a program associated to make things easy enough to get started. Once you have the other logic working in your application, you might be able to add interesting features like fallback to a default application in the absence of an existing file association.
On a Mac, you're already halfway there; open opens a file in the default application. By default it opens a reasonable editor for text files and XCode for Ruby files; I don't edit Ruby in XCode, but I could change the association if I wanted.
The name of the file that started a Ruby program is in $PROGRAM_NAME, so you can do
def dev_mode
if ARGV[0] == '--dev-mode'
system("open #{$PROGRAM_NAME}")
end
end
On Unix-like systems, including OS X, you might want to use the value of ENV['EDITOR'] (the EDITOR environment variable) if it's set. That's a convention used by many programs.
I'll let others give answers for other operating systems.
I want to write some pretty, special characters taken from Web in my Shell Console with echo command. I want to write, for example, ▲ character, but it shows me ��� character. How can I solve the problem? Thanks!
I am using Ubuntu 64 bit also. You should check your terminal type and what kind of character-set does it supports. Take a look at this
and this
You need to make sure you character sets match and that you are using the correct terminal emulation. This can be set on both the Linux side or using your terminal client software.
e.g. ANSI, VT100, Linux
Character sets like UTF-8 does include symbols.
On the rare occasion that I have to use a windows command prompt rather than bash, it drives me nuts that tab completion doesn't add a slash to the end of directory names. Is there a setting or script that I can run to force the full completion?
The answer these days is PowerShell. It is superset of the windows command line. It has many of the Linux commands. It has an object-based pipeline and has full access to the .NET framework from the command line.
And it adds a trailing slash when using tab to expand a directory name.
No there is no such setting. Your best bet is to use bash through cygwin but I expect you already knew that bit.
this is quite an old thread but I thought it might still be helpful for others.
I could not find a parameter in Windows to do the trick but I found a executable (GNU, with the Pyton source available) named PyCmd which is an improvement (according to my and my work habits) to regular CMD console.
It can be launched by double click it and it starts a regular console with cmd.exe and it loads itself in the memory to allow a lot of command line editing goodies, among them the same TAB completion behaviour I used to have under Unix Korn Shell (including the Emacs-like keys) with the trailing slashes or back-slaches for directories.
You can find it at:
https://sourceforge.net/projects/pycmd/
The last version is a December 2017 snapshot (but stable for me, could not meet any major trouble compared to the 2013 0.9 stable release), at:
https://sourceforge.net/projects/pycmd/files/pycmd/snapshots/
You can also launch it from an existing console, from CMD.EXE and it starts a sub shell with all its editing goodies. You exit this sub-shell by exit or ^D on an empty line.
Note that I have tested it to under an alternative console like "Hyper" (MIT License, at https://hyper.is/ and https://github.com/zeit/hyper), which I prefer compared to Windows default console, and it works perfectly with it too. I think it's fair to assume that it will work well for other consoles like ConEmu or others, but I did not test it with them.
This answer goes perhaps a little far beyond the original question but -- I hope -- still can provide some help to people like me who like to get the same kind of command-line behaviour as they used to have under Unix Korn shell (possibly Linux bash, I don't know).
Have a nice command line interface to all!
GM
I have a PHP program that uploads a CSV file and reads through it.
We only have PC's in the office, but sometimes our clients have Macs. Is there a way to create a Mac CSV in Windows for testing purposes?
Since CSV is a text-based format, the only difference between a Mac and a PC CSV file would be the line endings. Windows typically use CR+LF for line endings, whereas Mac OS X and *nix typically use just LF.
It really depends on the software that will be reading the CSV file. There is a good chance that a well-designed reader (on either Mac or PC) would gracefully / automatically handle either LF or CR+LF endings. However, there is (naturally) no shortage of not-so-well-written software out there. Do you have more info on what software they will be using?
If you want to explicitly create a CSV file in "Mac-friendly" mode, you could open the file in binary mode, and explicitly use "\n" (rather than "\r\n") at the end of each line. This will likely open / view fine on most apps within windows. (Though Notepad won't like it, Excel probably will.) This file should then be "optimized" for Mac output. Though, as above, it might not matter at all, if the client's software is "tolerant" of different endings.
EDIT: Prior to OS X, Mac used CR (\r) for line endings. For OS X, they switched to LF (\n). Most likely, your clients are using OS X, so \n is likely the ending you want.
There's no such thing as a 'Mac CSV'. A CSV is a document with values that are comma-separated (that's why they call it a "Coma-Separated Values file). In other words, it's plain text.
The only edge cases I could see are line endings (which is likely to be \n but could also be \r) and encoding (which is very likely to be UTF-8 but could somehow be Mac Roman) if your clients use non-ASCII characters.