When using mingw64, should the file path use A or B - c

I use mingw64 to write c programs on Windows 10. I heard that the c compiler is ported from Linux to Windows, and the separators used in the file path of Windows and Linux are different, so should I use "/" or "\" when writing programs?

Always use /. The Windows API understands C:/ as well as C:\ while for Posix systems \ is a character like any other, so one directory can be actually be named foo\bar in such systems. Programs aiming for portability use / as a directory separator.

Apart from Ted Lyngmo's answer, \ sometimes used to escape the next character, example: before my edit, your question did not show the \ character, the second " in "\" was shown as " instead of \".
So, use / to avoid confusion.
Example of a mistake that happens due to \:
#include <stdio.h>
int main() {
puts("\");
}
will cause an error in usual compilers saying missing terminating " character.
And paths such as C:\example\abc\x20 will become gibberish text and one thing that I am sure is that \x20 will become a space, and pass the compiler error detection.

Related

C program not compiling in vs code mac no such file or directory

This thing comes whenever I try to compile though I downloaded mingw w 64 it shows this only what to do
You should enclose file names that contain space in quotes or escape the space with \

Can I change the text color through sprintf in C?

I'm new to C and I came across this code and it was confusing me:
sprintf(banner1, "\e[37╔═╗\e[37┌─┐\e[37┌┐┌\e[37┌─┐\e[37┌─┐\e[37┌─┐\e[37┌─┐\e[37m\r\n");
sprintf(banner2, "\e[37╠═╝\e[37├─┤\e[37│││\e[37│ ┬\e[37├─┤\e[37├┤\e[37 ├─┤\e[37m\r\n");
sprintf(banner3, "\e[37╩ \e[37┴ ┴┘\e[37└┘\e[37└─┘\e[37┴ ┴\e[37└─┘\e[37┴ ┴\e[37m\r\n");
I was just confused as I don't know what do \e[37 and \r\n mean. And can I change the colors?
This looks like an attempt to use ANSI terminal color escapes and Unicode box drawing characters to write the word "PANGAEA" in a large, stylized, colorful manner. I'm guessing it's part of a retro-style BBS or MUD system, intended to be interacted with over telnet or ssh. It doesn't work, because whoever wrote it made a bunch of mistakes. Here's a corrected, self-contained program:
#include <stdio.h>
int main(void)
{
printf("\e[31m╔═╗\e[32m┌─┐ \e[33m┌┐┌\e[34m┌─┐\e[35m┌─┐\e[36m┌─┐\e[37m┌─┐\e[0m\n");
printf("\e[31m╠═╝\e[32m├─┤ \e[33m│││\e[34m│ ┬\e[35m├─┤\e[36m├┤ \e[37m├─┤\e[0m\n");
printf("\e[31m╩ \e[32m┴ ┴┘\e[33m┘└┘\e[34m└─┘\e[35m┴ ┴\e[36m└─┘\e[37m┴ ┴\e[0m\n");
return 0;
}
The mistakes were: using \r\n instead of plain \n, leaving out the m at the end of each and every escape sequence, and a number of typos in the actual letters (missing spaces and the like).
I deliberately changed sprintf(bannerN, ... to printf to make it a self-contained program instead of a fragment of a larger system, and changed the actual color codes used for each letter to make it a more interesting demo. When I run this program on my computer I get this output:
The program will only work on your computer if your terminal emulator supports both ANSI color escapes and printing UTF-8 with no special ceremony. Most Unix-style operating systems nowadays support both by default; I don't know about Windows.

vim substitute strange chars on printf after rsync

I edited (macvim) file.c here and then rsync it to the server. When I ssh in the linux machine and vim file.c I notived strange chars. In all printf, " changed to ?~#~\ in the left side and to ?~#~] in the right side.
printf("text");
appears as
printf(?~#~\text?~#~]);
I tried to :substitute
:s/\<?~#~\\>/"
But it didn't changed and I got
E486: Pattern not found: \<?~#~\\>
What might be the approach to that substitution?
In vim, ~ is a symbol for the last given substitute string, see here. You need to escape it.
The following will replace ?~#~\:
:%s/?\~#\~\\/"
And for the 2nd expression ?~#~]:
:%s/?\~#\~]/"
NB use :%s to substitute in the whole file.

What does slash in a header file name mean?

I was reading the gcc gnu-online-docs. I am confused about what it mentions regarding a \ or /in a header file name.
It says:
However, if backslashes occur within file, they are considered
ordinary text characters, not escape characters. None of the character
escape sequences appropriate to string constants in C are processed.
Thus, #include "x\n\\y" specifies a filename containing three
backslashes. (Some systems interpret ‘\’ as a pathname separator. All
of these also interpret ‘/’ the same way. It is most portable to use
only ‘/’.)
What does it mean by "some systems" in this paragraph? Does it mean the implementation depends upon the OS - Windows/Linux? (I know in #include <linux/module.h>, / specifies a path)
On Windows, both / and \ function as pathname component separators (dividing the name of a directory from the name of something within the directory). On basically all other operating systems in common use today, only / serves this function.1
By taking \ literally in header-file names, instead of an escape character as it is in normal strings, GCC's preprocessor accommodates Windows-specific code written with backslashes, e.g.
#include <sys\types.h>
where it is exceedingly unlikely that the programmer intended to include a file whose name is 'sys ypes.h' (that blank before the 'y' is a hard tab). The text in the manual is intended to inform you that such code will not work if moved to a Unixy system, but that if you write it with a forward slash instead, it will work on Windows.
I happen to have written the paragraph you quote, but that was more than ten years ago now, and I don't remember why I didn't use the word "Windows".
1 VMS and some IBM mainframe OSes have entirely different pathname syntax, but these have never been well-supported by GCC, and it is my understanding that surviving installations tend to have a POSIX compatibility layer installed anyway.
Remember that in ordinary strings, \n is a newline, \t is a tab, \a is an alert, etc.
The text means that if you write:
#include <sys\alert.h>
the \a sequence is treated as two characters, backslash and 'a', and not as a single character 'alert'. That is, the file is called alert.h and is found in a directory sys somewhere in one of the directories that the compiler searches for headers. Normally, inside a string, "sys\alert.h" would mean a name 's', 'y', 's', backspace, 'l', 'e', 'r', 't', '.', 'h'.
Similarly for:
#include <sys\backtrack.h>
#include <sys\file.h>
#include <sys\newton.h>
#include <sys\register.h>
#include <sys\time.h>
#include <sys\vtable.h>
(where I made up names as seemed to be convenient, and the sys can be replaced by any other directory name, and the <> by "").
#include <sys\386.h>
#include <sys\xdead.h>
#include <sys\ucafe.h>
#include <sys\U00DEFACED.h>
are also treated as regular strings rather than containing octal, hexadecimal, or Unicode escapes.
Windows is the main system where \ is used as the formal path element separator. However, even on Windows, the API treats / as if it were \.

Which path format to use in C on Windows, "D:\\source.txt" or "D:/source.txt"?

I only knew that we can't use D:\demo.txt as \d will be considered an escape character and hence we have to use D:\\demo.txt.But minutes ago I found out that D:/demo.txt works just as fine as we don't have to worry about escape characters with /. I am using CodeBlocks on Windows, and I want to know which one of these formats for path is valid for C on my platform.Here's my code and the commented-out lines work just as fine.
#include<stdio.h>
int main()
{
char ch;
FILE *fp,*tp;
fp=fopen("D:\\source.txt","r");
//fp=fopen("D:/source.txt","r");
tp=fopen("D:\\encrypt.txt","w");
//tp=fopen("D:/encrypt.txt","w");
if(fp==NULL||tp==NULL)
printf("ERROR");
while((ch=getc(fp))!=EOF)
putc(~ch,tp);
fclose(fp);
fclose(tp);
}
Windows (like MS-DOS before it) requires back-slashes as the path separator for the command line tools built into/provided by Windows.
Internal functions, however, have always accepted forward or backward slashes interchangeably. Personally, I prefer forward slashes as a general rule, but it's mostly personal preference -- either works fine.
It's true that Windows and MS-DOS accept either the forward slash / or the backslash \ as a directory path delimiter. And there are good arguments for using the forward slash in C code, because it doesn't have to be escaped in string and character literals.
But my own preference is to use the backslash (and remember to escape it properly), because most Windows users likely don't know that you can use / as a directory delimiter. It doesn't matter for an fopen call; these are equivalent (on Windows):
fopen("D:\\foo\\bar\\blah.txt", "r");
fopen("D:/foo/bar/blah.txt", "r");
But if that file name is ever shown to a user, IMHO it's a lot better if the message refers to D:\foo\bar\blah.txt.
You could use forward slashes for paths that are used only internally, and backslashes for paths that appear in the user interface, but that's going to be more difficult and error-prone than using one or the other consistently.
Incidentally, the C language says nothing about which character is used as a path delimiter; the language standard doesn't even specify directory support. It's determined by the operating system and file system.

Resources