I want to write in C a command line tool with the following requirements:
Few commands (<10)
History management through the arrows key
Capability to delete what I typed previously with baskspace
Capability to add keyborad shortcuts such as ctrl+l to clear the screen
Protable across UNIX systems
I am not asking for code here, but for indications about where to start. I first made some experiments with "scanf" and it quickly become quite complicated. I then looked at ncurses, and it seems also quite low level. Is there any C libraries dedicated to this task, where would you start ?
I then looked at ncurses, and it seems also quite low level
CDK (Curses Development Kit) - high-level wrapper over ncurses. I've had successful experience with it. When you need you always can use ncurses directly.
The GNU Readline library is exactly designed for that.
Related
I'm trying to write a small programme that needs to load a few files chosen by the user. I thought it'd be easier to use the Linux system's default file picker rather than write my own, but I literally don't have a clue where to even start looking.
So, can anyone recommend a quick and easy way to use the system's file picker on Linux in C?
As I commented, many Linux systems (e.g. a rented VPS, a consumer router box, ...) don't have any graphical user interfaces (often above X11).
If you want a GUI toolkit in C for Linux, consider using GTK. Then look at GtkFileChooserWidget & GtkFileChooser
If you want a GUI toolkit in C++ for Linux, consider using Qt.
If you want a terminal interface, learn ncurses.
If you want a web interface, use some HTTP server library like libonion or Wt, or make a FastCGI program for your existing web server.
Perhaps coding a simple shell script might be easier. Read Advanced Bash Scripting Guide. You could also use a scripting language like Python, Ruby, Ocaml, ...
If you don't know about Linux programming, read Advanced Linux Programming first. See also intro(2) & intro(3)
... a small program that needs to load a few files chosen by the user.
Just pass them as command-line arguments. It's much easier and doesn't tie you to a given GUI toolkit.
You can easily write a shell wrapper using kdialog on KDE, or dialog if you want curses in a terminal, or ... whatever other tool for whatever other environment.
I'd like to write an application (in C) that uses the terminal of a *nix OS as its GUI. I mean an application of the kinds of emacs, vi etc. that take up the whole terminal window and jump back to the input prompt after quitting.
How would you go about doing that, preferably in C? Can someone point me to a tutorial covering that?
You need to use ncurses:
http://en.wikipedia.org/wiki/Ncurses
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/
It is available on all major distros.
Well, actually this is not GUI (graphic user interface) but a text based interface. You can use the library ncurses to create such applications in C.
Use a library like ncurses, it is specifically designed for this purpose.
Throwing in alternate solutions so that this question thread does not look so monotonic:
the slang library (mc uses it, for example)
I've run into an issue with writing some code in c. My basic problem is that I am pressed for time and the code I am dealing with has lots of bugs which I have to "erradicate" before tomorrow evening.
The bigger part of the problem is that there is no adequate IDE that can do real time debugging, especially when using threads or spawning processes with fork(). I tried Mono, Eclipse, and finally NetBeans, and have concluded that those are very good but not for coding in C. More over the learning curve to utilize the command line debugger properly is quite steep. (Like I mentioned earlier... I am pressed on time.)
So, since I am a C# developer by profession I was wondering whether I can pull this off in VS2003/VS2005/VS2008/VS2010. If I abstain from using system calls, can I do this?
Of particular interest are FILE* descriptor and fread(), fclose(), fseek() methods. I know they are part of the standard C library, however are they tied to the platform itself? Are the headers the same in Linux vs Windows? What about fork() or shared memory?
Maybe if I use VS2010 to build parts of the component at a time (by mocking inputs and stuff), debug those, and then migrate the working code in the overall Linux project would prove most useful?
Any input would be greatly appreciated.
The bigger part of the problem is that there is no adequate IDE that can do real time debugging, especially when using threads or spawning processes with fork().
The Eclipse CDT would probably have the best overall support for C/C++ development and integrated debugging.
Note that multithreaded and multiprocess debugging can be difficult at the best of times. Investing in a good logging framework would be advisable at this point, and probably more useful than relying on a debugger. There are many to choose from - have a look at Log4C++ and so on. Even printf in a pinch can be invaluable.
So, since I am a C# developer by profession I was wondering whether I can pull this off in VS2003/VS2005/VS2008/VS2010. If I abstain from using system calls, can I do this?
If you take care to only use portable calls and not Win32-specific APIs, you should be ok. Also, there are many libraries (for C++ libraries such as Boost++ that provide a rich set of functionality which work the same on Windows, Linux and others.
Of particular interest are FILE* descriptor and fread(), fclose(), fseek() methods. I know they are part of the standard C library, however are they tied to the platform itself? Are the headers the same in Linux vs Windows? What about fork() or shared memory?
Yes, the file I/O functions you mention are in <stdio.h> and part of the portable standard C library. They work essentially the same on both Windows and Linux, and are not tied to a particular platform.
However, fork() and the shared memory functions shmget() are POSIX functions, available on *nix platforms but not natively on Windows. The Cygwin project provides implementations of these functions in a library for ease of porting.
If you are using C++, Boost++ will give you portable versions of all these system-level calls.
Maybe if I use VS2010 to build parts of the component at a time (by mocking inputs and stuff), debug those, and then migrate the working code in the overall Linux project would prove most useful?
You could certainly do that. Just be mindful that Visual Studio has a tendency to lead you down the Win32 path, and you must be vigilant to not start using non-portable functions. Fortunately the library reference on MSDN gives you the compatibility information. In general, using standard C or POSIX calls will be portable. In my experience, it is actually easier to write on *nix and port to Windows, but YMMV.
Looks like I am the first to recommend Emacs here. Here is how Emacs works. When you install it, it is simply a text editor with a lot of extensions(debugger and C font-locking are included by default). As you start using it and install the extensions you miss, it becomes more than just an editor. It grows to become an IDE very soon and easily, then on to something that can eschew the OS under one frame.
Emacs might take long to learn, in the mean time, you could use Visual Slick Edit if you are not pressed on the cost part. I have used it on both platforms and seen it work good with version control, tags, etc.
Perhaps Code::Blocks? I love it and while it says it's for C++ it is, of course, very good for plain C as well.
In our Bioinformatics lab we've recently been asked to create a GUI for a program written (and optimized) in C. Any GUI we designed would need to be able to feed input to and receive output from the C program, while also being easily portable to both Windows and Mac. What are ways to go about doing this?
If your looking for a GUI toolkit that works on windows/mac in C, have you considered GTK?
Download QT or wxWidgets.
Why do the hard work when someone already has and will let you use it for free? I prefer QT myself, btw.
Edit: It does mean using C++ but it will work perfectly with C code.
Use a separate program.
It doesn't break the existing code - especially important if the code has bio knowledge that a programmer might not know/understand/test.
Gui's change often, in a couple of years you are going to be rewriting the gui for NewSuperOsToolkit(tm) but the underlying worker code won't change. We have atmospheric modelling code that I'm sure was originally written in latin.
You keep the ability to run the engine code as a batch, in parallel on MPI in the cloud, and a bunch of other ways you haven't thought of.
You could write the front end GUIs in Java, and have them feed input and receive output from your C programs. I've known a couple of groups here at work that do something similar with C# and C code (but they don't have the multi-platform restraint).
This way you don't necessarily have to create your GUIs using a C toolkit.
Depending on the nature of the program, you could create an entirely separate GUI application (in any language you prefer), and fork/execute the existing program from it, redirecting it's stdin and stdout to your GUI program. Depending on how the existing program works, this could work well, or be very cumbersome.
You could also extend the existing program with GUI code in something like GTK (which has a C API), or you could use Qt (which is C++, but there's usually no problems calling C functions from C++ if you define them as 'extern "C"').
There are a number of scripting with languages that can make this easy. I'd go for tcl/tk it works on mac pretty much out of the box, and is cross platform across pretty much any machine you can think of.
Also GTK is great and a number of scripting languages have bindings for it.
You probably don't want to write your gui in c if you don't have to. use a rapid develoment scripting language.
If you want a native GUI, then go with wxWidgets or QT. (I use wxWidgets ...)
The alternative is to have an HTML based interface using Javascript and CSS. You avoid GUI libraries altogether, you get cross-platform support and the outcome is better on some dimensions, worse on others.
If you really want a standalone user interface, you can integrate it into a binary with something like WebKit.
I think the thing I want to do is called GUI/command line wrapping sftp(1). I need an easy way to start that program and react on its output while running. Additionally I have to be able to send input to it, full interaction is required.
I tried forkpty (emulated TTY), but there wasn't one good example findable using forkpty for that job, instead several warnings about overflows in in arguments and advisories not to use it. Another weird thing about this was the windowsize argument...
Please either give me one or many example(s) on how to call & interact with command line programs in C or another way of integrating sftp in an iPhone GUI
Rejoice! Expect was created to solve exactly your problem. It's based on Tcl, which is not so pleasant, but the tool is pleasant, it's really well designed, and there's a good book by Don Libes, who created the tool.
Expect scripts are written in Tcl, but it is totally easy to integrate a Tcl script into a C program such that other parts of the C program don't even know that Tcl is being used.
Have you used any of the popular scripting languages Ruby/Python/Perl/etc? They all have pretty full featured libraires for opening and communicating with other processes.
the subprocess module in python for example, or Popen in Ruby... there would also be lots of reference material around the web to help you out.
If a GUI was also required you could look at GTK extensions
Instead of calling sftp(1), how about using libssh? It has full sftp subsystem support.