I was trying to understand sqlite source code.
I was lookin to find that, when on CLI we do $sqlite abcd.db, where does the control transfers to , which function are called?
I've to make some changes whenever I create a new database or open it i.e. $sqlite abcd.db
The amalgamation build of SQLite includes two C files. sqlite3.c is the SQLite library source code, and does not contain an entry point, since it is not a program.
The SQLite shell is implemented in the file shell.c, which is a standard C program source file with a main function (which is on line 3570 in my version).
Related
I am currently trying to build a new version of a piece of software I developed. The software takes a simple command line argument and appends the argument to the end of a file. My problem is that I want to alter the program so:
Someone can set up a standard location to save the file to.
The program will remember that location.
It will still work for anyone installing the C program on mac, linux or windows.
So basically I am trying to figure out how to create a C executable that comes with persistent memory that it can read and modify. Alternatively I would take any way to create an installer to make this easy for anyone who wants to use my program.
If this were a java program I would just add it to the jar file but I have never seen this documented for the C language.
I would add platform-specific code to store your settings in whatever area users of that particular platform expect. So:
For Linux: store configuration files in the location specified by $XDG_CONFIG_HOME.
For Mac: Use CFPreferences
For Windows: use the registry
I have to create one-file (.exe) program.
In this program user can choose directory from his computer.
I create program in order of http://www.tarnyko.net/en/?q=node/31 and it run well.
But when I invoke FileChoser (click on button) I got this error
GLib-GIO-ERROR No GSettings schemas are installed on the system
Response of Tarnyko to this issue is in coment on webpage - this is known "bug" with static compiling.
How can I work around this?
On the one hand I have to have one-file.exe.
On the other hand I realy do not want create "sophisticated" FileChooser on my own... is there any option to deal with this?
My ideas:
1 - Call native File chooser of OS (windows)
2 - Create file chooser on my own - if it is not "much hard" in gtk
I do not know how to do either of this.
Sorry for duplicating - probably succes solution is in answer form "ebassi" here GLib-GIO-ERROR**: No GSettings schemas are installed on the system (not tested yet)
Settings schemas (which are used in GTK in more places than just the file selector widget) cannot be statically linked into a binary: they have to be installed in a well known location (controllable via the $XDG_DATA_DIRS environment variable) and they have to be compiled into a cache.
GTK's dependencies like Pango and GDK-Pixbuf also use ancillary files and loadable modules that are not strictly compatible (unless you're willing to spend time on it) with static linking.
The usual recommendation for only providing a single executable for your application is to have a self-extracting installer that contains all the installed files necessary to running a GTK application, and avoid static linking.
I don't think it's possible to create just one .exe file (without any other files) with GTK+. Maybe only when you recode the GTK and it's dependencies - which is not an easy task to do.
The best solution I found is to put all schemas (and also icons for your GTK+ app) in the same location where your .exe file is placed:
EXE_LOCATION\program.exe
// For icons:
EXE_LOCATION\share\icons\hicolor...
// For schemas
EXE_LOCATION\share\glib-2.0\schemas
Then you deliver these files together with your .exe file and with all needed .dll files.
About the native file chooser in GTK+: It also needs the schemas - at least on Windows OS.
Below is the scenario for my problem for pro*c code.
In my new project previously they used the batches to call the pro*c code. But due to new requirement we need to call the same code from online(forms). They are 4-5 .pc files which needs to be called on same action asynchronously.
For above I thought to create another .pc file which will call these 4-5 .pc files. But I don't know whether we can call one .pc file in another .pc file. The code which is existing is very huge.
If we can call, can I have some idea how we do that?
Your .pc files which are currently being run as part of the batches will presumably have been compiled into executable binaries that are being run.
This is an Oracle forms question rather than a Pro*C question. You need to work out how to execute these binaries from Oracle forms rather than as part of the batches.
See http://docs.oracle.com/cd/B10501_01/appdev.920/a97269/pc_20exi.htm for information on how you might do that.
I have gcc in my Win8 path and can compile C files from the Windows command prompt which is great and I have been compiling regularly in this way but just now I have been looking at creating a makefile to use and compile with.
My first makefile failed as I created makefile.txt but when I removed the file .txt extension the compile worked successfully with the make command at the cursor in cmd console.
The makefile then has no file extension and my query is how the xxxx does this work? Windows obviously knows what this file is and uses it with gcc to compile but how/why? This leads on to another question ...are there other files made with no file extension that do stuff on Windows (or other OS)? I'm perplexed and intrigued and would appreciate a technical explanation if possible.
Thanks.
EDIT...Sat 291114
I am working through Learning C the hard way by Zed Shaw and this image shows Ex2 creating a makefile on my Win8 PC..
It works because the make program is written to look for files named makefile, not files named makefile.txt.
Extensions are important on Windows so that Windows can guess what "type" of file it is, so if you tried to open that file Windows could guess at what program should be used to open it.
However, this is really a problematic solution. First, just because two files have an extension of "foo" doesn't mean both are the same type of file; there's no central authority of file extensions (that I'm aware of) to guarantee there are no conflicts. Second, just because a file has an extension "foo" doesn't mean the contents are of that type: I'm sure you're familiar with viruses and scams where a file of one type is created with a different extension to trick Windows into running an unexpected program.
On traditional UNIX-based systems the "type" of a file is usually derived from the contents of the file, not the extension. There are some obvious exceptions, for example source files are all plain text files so they have the type of code it is (C, C++, Java, Python, etc.) marked by the extension. But on UNIX systems, for example, programs do not have .exe extensions: for example it's just make, not make.exe. Also a shell script doesn't have to end in .bat or .com: it can be just named foo as well if you want. For executable files the operating system looks at the first two bytes of the file to tell what kind of executable it is. For scripts the first two bytes must be #!: then the operating system knows it needs to run an interpreter (like the shell, or Python, or whatever) for the script.
For non-executable files like JPG or whatever, programs can determine their type by examining the contents. Most file types have some format to their content that can be used to say "this is a JPG file", "this is a MP3 music file", etc.
I am writing a program in C on Linux environment (Debian-Lenny) and would like the program to be updated when an update is available (the program gets notified when a new update is available). I am looking for a way that the program can update itself.
What I am thinking is that the main program invokes a new program to handle the update. The updater program will have(access to) the source code and receive the update information about the changes on the source code, something like that:
edit1: line 20, remove column 5 to 20;
edit2: line25, remove column 4-7 then add "if(x>3){" from the column4
edit3: line 26, enter a new line and insert "x++;"
then kill the main process, recompile the source code, and then replace the new binary with the old one.
or is there a better (easier) and standard way to implement the ability that a program can update itself?
I use the program to control a system with a Linux embedded board. Therefore, I don't want the source code to be accessible to another person (if the system is hacked or something).
If the best way to update a program by using the source code, how do you suggest me to secure the source code? If you suggest me to encrypt the source code, what function (Linux C) can the program use to encrypt and decrypt the source file?
If your target system is Debian, then you should just take advantage of the Debian packaging system to provide updates. Package your compiled application in a .deb package, distribute it on an APT archive which is included in your system's sources.list, and just use cron to schedule a regular update check with apt. The .deb package can include a post-installation script that restarts your application.
You could run an apt-proxy caching proxy on your "gateway" nodes that have internet access, and have the other nodes use that as their apt source.
Distributing source code in this case is probably not appropriate, because then you would need to include a full compiler toolchain on your target system.
What you're describing is very similar to the 80s-style of delivering Unix source code, popularized by the development of PERL. You use diff to get a record of changes between different versions of the source-code, then distribute this "patch" file, and use patch to perform the necessary modifications at the client-end. This doesn't address the network-communication or version-control issues.
A possible downside is that a first-time download may need to apply many patches to bring the version up. This is often the case when investigating old source from nntp:comp.sources.unix.