I want to localize my application using the catopen()/catgets() family of functions.
As far as I understand, in the absence of NLSPATH variable, message catalogs will be looked up under /usr/share/locale/xx_YY/LC_MESSAGES.
What is the "traditional" file extension for message catalog files? I see some code examples using *.cat while others don't use any extension at all. Is it dependent on a particular UNIX flavour?
On my Linux boxes I see plenty of *.mo files, but those are GNU gettext archives. It seems catgets() can rarely be seen "in the wild" nowadays.
I meant this to be a comment, but it's a bit too long :P
Looking at the doc you've linked to, it seems probably that the code isn't opinionated as to file extension. Since you're not using MIME or anything to automatically find a handler for this file, the only requirement is likely to be that the name is correct. In UNIX, especially in the shell, file extensions often mean nothing to the system - fo example, any file extension can be used on an executable script as long as the executable bit is set and the shebang line at the top of the file specifies an appropriate interpreter.
It's possible the user community, if one still exists for this crufty sounding library, has a standard naming convention that the docs don't describe - but I wouldn't sweat it too much. It's trival to change file names, even if it means a recompile ( command line variables would make the program agnostic as to file name and extension )
Related
I found a pacman project in github where a file conf.c includes a header file #include "ini.h" where ini.h contains only a single line (i.e no #include statement):
//ini.h
../common/ini.c
I have never seen anyone doing this before! It seems a bit hackish/rough around the edges. My questions are:
Is this legal C?
Is it portable?
Is it recommended?
I would have assumed the answer should be no for all these questions, but I may be learning something new...
edit
From the answers, I see its a Linux symlink. I guess that this means it is not portable to Windows, and would also make it more difficult to read outside a unix environment. I would also imagine that using relative paths (or include directories) instead of symlinks would be a better practice in cases like this for reasons mentioned above...
src/pacman/ini.h is a symbolic link according to the site.
Symbolic link has an information of where the target file is (path name), and I guess it is what is displayed on the site.
The OS will redirect access to that ini.h to ../common/ini.h, which is a normal C code.
I don't see any reason why not. The include statement indicates the compiler to replace that line with the whatever is in the included file
Is there a C library function to get the extension of file? I know that I can design a function on my own to get extension after '.' but not all files are stored with their extensions when we read them.
So you'd like to get the type of a file? Maybe the command 'file' in Linux is what you want. You can check its source code.
The file command in Linux uses a library called libmagic (don't confuse with libmagick) to check the 'magic' bytes in the file itself to determine the likely content type.
The library is fairly cross platform, it's well documented, for example here:
http://linux.die.net/man/3/libmagic
I am trying to understand the different file extensions for the pfxplus powerflex database. Could someone please help telling me briefly what each file is for?
.k1
.k2
.k3
...
.k13
.k14
.k15
.fd
.def
.hdr
.prc
.pc3
Data files:
OK, so .dat is the data file.
.k1 -> .k15 are index files.
These are the critical data files for runtime. (Combined with filelist.cfg or pffiles.tab similar to define what files are available overall).
.fd is the file definition, needed for compiling programs
.tag (which you did not mention) is needed only if you need to access field names at run time (such as using a generic report tool)
.def is the file definition in human readable form, and is not needed by any process but is produced so a programmer or user can understand the file structure.
Run time:
The .ptc files are the compiled threads interpreted by the powerflex runtime.
The .prc file is a resource file that is used at runtime in conjunction with the .ptc file - it defines how a character based program is to look in a gui environment in "g-mode". It was the cheap way to upgrade character based programs when windows first started getting popular usage.
.hdr and .pc3 escape me at the moment, but are vaguely familiar - .hdr is probably another data file used with compression or special field types for later versions of pfxplus. .pc3 may in fact be the .ptc files...
I have a huge project, whole written in C language and I have a single make file that is used to compile it. The project C files contains lots of capitalize problems in it's header files, meaning there are tones of header files that were miss-spelled in lots of C files.
The problem is I need to migrate this project to compile on Linux machine and since Linux is case sensitive I got tones of errors.
Is there an elegant way which I can run make file in Linux and tell him to ignore case sensitive?
Any other solution will be welcome as well.
Thanks a lot.
Motti.
You'll have to fix everything by hand and rename every file or fix every place with #include. Even if you have a huge project (comparable with linux kernel), it should be possible to do this during a hour or two. Automation may be possible, but manual way should be better - because script won't be able to guess which name is right - filename, or the name used in #include.
Besides, this situation is a fault of original project developer. If he/she wasn't sloppy and named every header in every #include correctly, this wouldn't happen. Technically, this is a code problem similar to syntax error. The only right way to deal with it is to fix it.
I think it takes not too long to write a small script, which goes thru the directories first, then replaces C headers. Explained:
Scan the headers' folder and collect filenames.
Make a lowercase list of them. You have now original and locased pairs.
Scan the C source files and find each line contains "#include"
Lowercase it.
Find the lowercase filename in the list collected and lowercased from headers.
Replace the source line with the one collected from headers.
You should put the modified files into a separate folder structure, avoid overwriting the whole source with some buggy stuff. Don't forget to create target folders during the source tree scan.
I recommend a script language for that task, I prefer PHP, but just it's the only server-side script language which I know. Yep, it will run for a while, but only once.
(I bet that you will have other difficulties with that project, this problem is not a typical indicator of high quality work.)
Well I can only tell you that you need to change the case of those header files. I don't know that there is any way you can make it automatic but still you can use cscope to do it in a easier way.
http://www.linux-tutorial.info/modules.php?name=ManPage&sec=1&manpage=cscope
You can mount the files on a case-insensitive file system. FAT comes to mind. ntfs-3g does not appear to support this.
I use the find all and replace all functionality of Source Insight when i have to do complete replacement. But your problem seems quite big, but you can try the option to replace every header file name in all occurences of source files using the
"Find All" + "Replace" functionality. You can use notepad++ too for doing the same.
A long time ago there was a great tool under MPW (Macintosh Programmer's Workshop) called Canon. It was used to canonize text files, i.e. make all symbols found in a given refernce list have have the same usage of upper/lower case. This tool would be ideal for a task like this - I wonder if anything similar exists under Linux ?
When I work on someone else's code, I tipically need to abuse of grep in order to find data types declarations etc, and this usually makes me confused.
I'd like to have some tool which analyzes the source code and produces some graphviz-like drawing and allows me to follow dependencies.
Also I've found this on the internet, but I think is taylored for the linux kernel only.
Have you tried doxygen?
Doxygen can produce dot files, and you can build the documentation without changing the source code with the right options set in the Doxyfile.
Do you use an editor that can take advantage of tags ? In Emacs, I just type M-. to go to the definition of a symbol, and M-* to go back to where I was once I have read it. This also enables the command tags-search to grep among the files of the software project (very convenient if they are in multiple directories).