Is wrapping a command-line tool (wget, curl) a “good” practice?

Question

I have a background in .NET, specifically in C# WPF and ASP.Net, but now I am going to use more golang and C. Consider the following situation as an example:

The software I should program should should basically upload data and present that upload-process using a GUI. Each language used in production has usually (extern) classes/libraries that provide (Network)Stream-I/O, but it's lots of more work to program an abstract "Network-Framework" (because often you have to use TCP/IP-Sockets and other low-level stuff, which is a huge origin of complexity [when your company doesn't provide such functionality already]), adjusted to the needs of my program, than using curl. The upload-function of my program could only wrap curl, a well tested and widely used and accepted tool for this purpose, which has lots of options. I know that this "loss of control" is a huge disadvantage, but curl also offers data-output which I can use as communcation-interface between my program and this tool. When they are no acceptable libs out there, that offer such features, is it "legit" to use curl for a professional product?

Answer 1

My take:

1. Reinventing the wheel is bad. Don't do it. We all know this.
2. Wrapping a command-line tool is always a bit ugly. Lack of useful integration, lack of flow control, having to worry about all sorts of quoting hell.

However in this case, there's a perfect solution: just use libcurl. It's what makes up the guts of curl anyway and you get to avoid all the nastiness of wrapping a command-line tool.

Answer 2

Wrapping a command line app is not good or bad, its just a technique.

The 'good' vs 'bad' comes into play when you look at the alternative approaches. Its less likely to be 'good', for example, if you are wrapping a command line executable when a more suitable library is available to you. On the other hand, there's absolutely nothing wrong with wrapping the command line executable when that's the only available tool for what you are doing.

In your specific case, I'd be very surprised if there weren't many other options available to you beyond wrapping cURL.

Answer 3

I think it's more a question of whether you want this functionality embedded in your software or not. No matter how it shakes out, if the functionality is required you're going to end up with a "curl" somewhere. But I'd caution you that there is complexity either way.

If "curl" is inside your software:

Then you need to code it up yourself and yeah that's a pain but libcurl is pretty damn solid as far a libs go and as long as your code builds you can rest easy that the user is good to go.

If "curl" is external to your software:

Then yes it's easier for you on the coding side but you have in a very real sense converted your low level programming work into system administration work since now you'll,

• need to make sure your software can find curl on the system. (Deployment into different environments gets complicated)
• deal with users on systems that don't have curl installed. (How big a deal this is depends on your target platforms but you'll need to make sure people know how to install it if they don't have it already.)
• (likely) need to create a general configuration system that allows the user to help the software find curl (or something equivalent) that allows your software to operate when curl is already present but the method you provided failed. A good config file setup can help here...

System administration and robust deployment into different environments can get complex (just like straight up coding) so to me it seems like there are advantages and disadvantages to both.

Choose your poison.