I've got the following issue:
int main(int argc, char **argv){
while(1){
char command[25];
scanf(" %25[^\n]s", command);
printf("Command '%s'\n", command);
}
return 0;
}
Now whenever I type something in the console it prints me a message with what I just typed.
But if I use the arrow up key to get the last command out of the memory, the command being sent is
^[[A
Which results in the cursor being moved up by the program.
Now how do I fix this?
I want that the last command from memory is triggered.
Thanks in advance!
This is actually pretty non-trivial thing you are asking for. Luckily, there is a library to fix it: GNU Readline library. Be aware about its licensing, though. Last I heard, it's actual GPL and therefore your own program needs to be that, too, if you use it. NetBSD has a library called libedit, which seems to claim to do much of the same thing with less restrictive license.
Here are some more help with readline: https://eli.thegreenplace.net/2016/basics-of-using-the-readline-library/
And if you can stomach the idea of not integrating it directly into your own program, there is a handy utility program called rlwrap, which provides the end-user at least some of the goodness transparently.
Related
I need to run a program that crawls websites and I already have an algorithm and some parts of the code. Problem is, I do not know how to insert wget into my source code. Our student assistant hinted that some kind of keyword or function shall be used before the wget( system, I think or something but I'm not so sure).
when to not use system:
1.) when you want to distribute the program to different environment, where the program you call via system is not available
2.) in a security relevant environment, where you have to make sure that the program you call is really the program you want it to be
3.) when the thing you want to do can easily be accomplished in 10-20 lines of C code
4.) in performance-critical applications
so, you should use system virtually never.
instead, to accomplish the same thing, you could use libcurl, as David suggested (his answer seems to be gone...), or do some socket programming (it's C, after all).
In a real-world scenario, I'd probably just default to writing the crawler in a different language. web requests and complex string processing are not necessarily the strong sides of C, and most definitely not very convenient to use :)
You can use the system() command.
In your case (possibly):
system("/bin/wget");
But if you want really call wget with parameters, so you should use execl().
execl("/bin/wget", "http://anyadress.com/file");
Whenever , you want to run shell commands from your C program , you use system("shell command").In your case
system("wget");
Note - wget is an executable , whose location is added to the path variable, so there is no need to specify the path explicitly.
-- Example --
#include <stdio.h>
#define BUFFLEN 2500
int main()
{
char web_address[BUFFLEN] = "www.google.com";
system("wget 'web_address' ");
return 0;
}
The system command is used to execute a shell command. man system
I'm curious if someone can point me in the right direction here. I'm learning about computer systems programming (the basics) and I'm trying to trace code through different levels to see how each interacts with the other. An example would be calling the fgets() function in C or getline() in C++ or similar. Both of those would make calls to the system right? Is there an easy way to look at the code that is called?
I'm working on Unix (Ubuntu). Is this something that is proprietary with Windows and Apple? Any good resources out there for this kind of thing? As always, thanks guys!
At least in the UNIX world, the answer is fairly easy: "Use the Source, Luke".
In your example, you would look at the sources for, say, fgetc(). That's in the C standard library, and the easiest way to find the source is google something like "C libraary fgets() source".
When you get that source, you'll see a bunch of code handling buffers etc, and a system call, probably to read(2). The "2" there tells you it is documented in Chapter 2 of the manual (eg, you can find it with man 2 read).
The system call is implemented in the kernel, so then you need to read the kernel source. Proceed from there.
Now, what you need to find this all without having to read randomly about in the sources (although that's the way a lot of people have learned it, it's not very efficient) is to get hold of a book on Linux like Kerrisk's The Linux Programming Interface, which explains some of these things at a somewhat higher level than just the source.
Something fgets is located within libc. That is, it's a userland library linked with most C binaries. Check out glibc, which is currently the most common implementation.
Eventually, libc will start making system calls to the kernel. You can get the source at kernel.org. Check out KGDB for kernel debugging. The simplest way to to do kernel debugging is to use a second machine connected via null model cable.
On Windows, you could get some insight with a few things. First you'd need something called symbol files that correspond to the binaries you'd like to investigate. Symbol files associate textual names with the global/stack/heap variables floating around a program. So to map the address in memory to the function fgets, and see fgets in certain programs you'd need to have the symobls for the version of Microsoft's implementation of the C std library. Lucky for you MS makes their symbols freely available
Second you would need to capture a callstack that dove deeper than fgets. The most obvious way to do this would be to be a Microsoft developer and introduce a crash into a deep MS dll, then analyse the crash dump with a debugger and symbols, but unfortunately we can't do that. What you can do is use whats called a sampling profiler, as in this one freely available from Microsoft. A sampling profiler profiles your code by taking periodic snapshots of the callstack of your program. Using symbol files from Microsoft, we can digest that callstack into something meaningful.
Given those 2 pieces of info, it wouldn't be hard to construct a program and get some insight into what fgets calls. You can then use the sampling profiler with Microsoft's symbols to get an idea of whats going on during your program.
Along these lines I constructed the following program to try this out:
int FgetSTest()
{
FILE* fp;
fp = fopen("C:/test.txt", "w");
char data[100];
int sum = 0;
for (int i = 0; i < 100; ++i)
{
fgets(data, 100, fp);
sum += data[0];
}
fclose(fp);
return sum;
}
int _tmain(int argc, _TCHAR* argv[])
{
int sum = 0;
for (int i = 0; i < 100; ++i)
{
sum += FgetSTest();
}
std::cout << sum;
return 0;
}
Assuming you've compiled this into a program (I've compiled it into one called perfPlay.exe) you can run MS's sampling profiler on the exe as follows:
C:\path\to\exe>vsperfcmd /start:sample /output:perfPlay.vsp
Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.
C:\path\to\exe\>vsperfcmd /launch:perfPlay.exe
Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.
Successfully launched process ID:3700 perfPlay.exe
sum is:40000
C:\path\to\exe>vsperfcmd /shutdown
Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.
Shutting down the Profile Monitor
------------------------------------------------------------
Get profiler output, notice the "symbolpath" switch to point the command to Microsoft's symbol server:
C:\path\to\exe>vsperfreport perfplay.vsp /summary:all /symbolpath:srv*c:\symbols*htt
p://msdl.microsoft.com/download/symbols
You can examine the csv directly of the caller-callee report, or find a good viewer, like the one I've been working on, and you can get an idea of where fgets spends most of its time:
Sadly, not terribly insightful. Unfortunately, one of the problems you'll run into with this approach is that many of the functions fgets calls in release mode could very well be inlined -- that is they are pretty much removed as functions from the final program and their contents directly "pasted" in to where they're used.
You could try repeat the above in debug mode to see what you get, as there's less chance of inlining.
First things first; this task will require good tools. I find etags, cscope, and gid (from GNU idutils) indispensable tools when navigating source. Figure out how to integrate one or more of these into your favorite editor or IDE. Switch editor or IDE to get these features, there's no excuse for poor tools. If you're looking for advice on one, I love vim, a vast many people argue for emacs, and there's some folks who love their Eclipse.
You'll want the sources locally; lxr is an amazing tool, but the latency involved in repeated web requests gets tiring for any serious work. On Debian-derived systems, this is pretty easy; change directory to wherever you wish to store the source and run apt-get source eglibc to download the glibc sources. I suggest getting the kernel sources via a tarball from http://www.kernel.org or cloning the master git repository (a better choice if you want to read changelogs or easily get updates -- though it does expand to 2.7 gigabytes as of June 2012, so it obviously isn't for everyone).
Once you've built tags files for the C library, you can just run: vim -t fgets and it will open libio/bits/stdio2.h directly to the source for the fgets() routine. (It is much less readable than you may hope.) Follow these around until you eventually get to a read() system call. (It may take a while.)
Now switch to the kernel sources. Look in fs/read_write.c for this this:
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
One downside to the way the kernel uses macros to define system calls is that it complicates searching for functions. vim -t can't find this directly. The easiest thing to do when looking for system calls is to run gid -s SYSCALL_DEFINE | grep read. (If you find a better tool, let me know.) Once you've found the system call entry point, it'll be far easier to read the rest of the kernel source. (I generally find it more legible than glibc sources, too -- though the days of being five or six function calls away from the block-level bread() call are long gone.)
Is it possible to write a program in C that upon execution deletes itself (the binary) and then terminates successfully. If so, what's the easiest way of doing this?
Yes.
#include <unistd.h>
int main(int argc, char* argv[])
{
return unlink(argv[0]);
}
(Tested and works.)
Note that if argv[0] does not point to the binary (rewritten by caller) this will not work.
Similarly if run through a symlink then the symlink, not the binary, will be deleted.
Also if the file has multiple hard links, only the called link will be removed.
I do not know that one can conveniently do it in a truly platform-independent way, but you didn't specify platform independence, so try the following, Linux-style code:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv) {
printf("Read carefully! You cannot print this message again.\n");
return unlink(argv[0]);
}
How close is that to what you want?
If you operating system allows a running program to delete its own binary, then just look for the API for file deletion, or execute a corresponding system() command.
If the OS doesn't allow this, your program (let's call it A) could construct another binary, containing another program (let's call it B). Then, A would immediately quit.
Program B would have a single loop checking if A is still running and as soon as A quits, B would erase A's binary.
You could try to just delete the executable in the program (FILE* and stuff)... but seeing as that executable is what's being run it might not work. I see it like eating yourself, and as far as I know it's not possible, but you could certainly give it a try using the method I mentioned above.
I think it is dependent on the platform you are using. Basically, once the executable is loaded, any subsequent change to the binary does not affect the running program. In Unix, this is the case, and you can use the unlink system call.
I am not sure whether this is true on Windows or not. It may not be allowed to delete the executable image. You can try the DeleteFile() api in Windows.
Here's some example code to give an idea of what I want.
int regular_function(void)
{
int x,y,z;
/** do some stuff **/
my_api_call();
return x;
}
...
void my_api_call(void)
{
char* caller = get_caller_file();
int line = get_caller_line();
printf("I was called from %s:%d\n", caller, line);
}
Is there a way to implement the get_caller_file() and get_caller_line()? I've seen/used tricks like #defineing my_api_call as a function call passing in the __FILE__ and __LINE__ macros. I was wondering if there was a way to access that information (assuming it's present) at run time instead of compile time? Wouldn't something like Valgrind have to do something like this in order to get the information it returns?
If you have compiled your binary with debug symbols, you may access it using special libraries, like libdwarf for DWARF debug format.
This is highly environment-specific. In most Windows and Linux implementations where debug symbols are provided, the tool vendor provides or documents a way of doing that. For a better answer, provide implementation specifics.
Debugging symbols, if available, need to be stored somewhere so the debugger can get at them. They may or may not be stored in the executable file itself.
You may or may not know the executable file name (argv[0] is not required to have the full path of the program name, or indeed have any useful information in it - see here for details).
Even if you could locate the debugging symbols, you would have to decode them to try and figure out where you were called from.
And your code may be optimised to the point where the information is useless.
That's the long answer. The short answer is that you should probably rely on passing in __FILE__ and __LINE__ as you have been. It's far more portable an reliable.
So, I'm trying to stuff some default text into a user input using readline, and having trouble getting it to work on OSX 10.5:
// rl_insert_text_ex.c
// gcc -o rl_insert_text_ex rl_insert_text_ex.c -lreadline
#include <stdio.h>
#include <readline/readline.h>
int my_startup_hook(void) {
return rl_insert_text("ponycorns");
}
int main(int argc, char *argv[]) {
char *line;
rl_startup_hook = (Function*) my_startup_hook;
line = readline("What's your favorite mythical animal? ");
if (NULL == line || '\0' == *line) {
printf("Nothing given... :(\n");
}
else {
printf("That's funny, I love %s too!\n", line);
}
return 0;
}
This code doesn't even compile on 10.4 (no definition for _rl_insert_text on 10.4, which is a bit of a bummer), but does compile on 10.5. However, the rl_insert_text()'d text is never shown to screen, nor returned as user input. The callback is being used and rl_insert_text() returns the proper value, (thank you, printf), so I'm not sure what's going on here.
I checked /usr/include/readline/readline.h, and rl_insert_text() is under:
/* supported functions */
which is confusingly under:
/*
* The following is not implemented
*/
So am I SOL, or am I just doing it wrong?
Unfortunately, you may be out of luck, at least with the readline library included in OS X. Due to license compatibility issues, Apple uses libedit, which (apparently) provides incomplete readline emulation. (This library is documented with the name "editline" in the readline.h included with OS X.)
GNU Readline Library (the "one true" readline library) is under GPL, which (being a copyleft license) does not play well with code that is not entirely open-source. If it comes down to (A) open-sourcing all of Xcode, OS X, etc. or (B) using a knock-off of what you're really like to use, Apple (like most companies) is always going to choose B. It's a bummer, but that's life.
Personally, I think this is one reason that GPL'd code is somewhat of a blight on the land, since in the act of "sticking it to the man", it often also withholds the code from the masses who purchase software. The {BSD,MIT,Apache}-style licenses are much more conducive to use in closed-source systems, and still allow commercial entities to contribute back patches, etc. My guess is that libedit hasn't received enough attention to be fixed properly. Community patches would certainly be welcome, although it's so much nicer if we can use code without having to hack on it ourselves... ;-)
BTW, the same thing applies to other GPL projects — as long as {git,mercurial,bazaar} remains under GPL, don't hold your breath for Apple to ship integration for them in Xcode. :-(
UPDATE: The new Xcode 4 offers git support. Huzzah! My understanding is that this is due to the new plugin architecture which isolates GPL'd code from the main Xcode codebase. However, I emphasize that copyleft licenses are still the wrong solution for code that should benefit everyone. Obviously some people don't agree (you're a pal, anonymous downvoter) but the fact is that GPL can restrict freedoms too — usually its different ones than closed-source/proprietary software generally does, but GPL is also quite effective at preventing illegal use of source code... The difference is a feeling of moral superiority.