I have created a wrapper around the sendmail executable, and it should not actually do anything unless sendmail is being invoked in its default mode of operation.
How to reliably determine whether this is the case?
What I have thus far:
the executable's name must be sendmail
none of the words on command arguments must be -I or start with -b except -bm
Will that be perfect - regardless of which implementation of sendmail is actually being used - or may it misclassify certain cases?
You should approach it from the other side. Check list of valid/acceptable command line options and treat all others as unacceptable. "Sendmail look alike" may accept quite non standard options.
BTW "sendmail from sendmail.org" is no longer installed (by default) as set root id.
Related
Is there a way to invoke bazel help such that it outputs a machine readable format. I would like to parse all the flags that are available in Bazel and make them automatically available in ibazel so that I don't have to manually sync them every time a new bazel release comes out with different flags.
There used to be a --helpxml argument that printed things out as XML, but it seems the command line argument parser has changed and you can no longer use that. I presume there is still some way to get this, since the docs are being generated with up to date command line info. Unfortunately the "edit this page" button on the docs site 404s and I can't figure out its origin.
The docs for the flags are generated via this genrule, which essentially runs bazel help everything-as-html, the source of which is here.
There are a few other options listed in that case statement, one of which being flags-as-proto which emits the flags as a base64 encoded version of the BazelFlagsProto.
Potentially ibazel could read this in, load in the proto and pull out the data from there.
I'm creating a unittest- and Selenium-based test suite for a web application. It is reachable by several hostnames, e.g. implying different languages; but of course I want to be able to test e.g. my development instances as well without changing the code (and without fiddling with the hosts file which doesn't work for me anymore, because of network security considerations, I suppose).
Thus, I'd like to be able to specify the hostname by commandline arguments.
The test runner does argument parsing itself, e.g. for chosing the tests to execute.
What is the recommended method to handle this situation?
The solution I came up with finally is:
Have a module for the tests which fixes the global data, including the hostname, and provides my TestCase class (I added an assertLoadsOk method to simply check for the HTTP status code).
This module does commandline processing as well:
It checks for its own options
and removes them from the argument vector (sys.argv).
When finding an "unknown" option, stop processing the options, and leave the rest to the testrunner.
The commandline processing happens on import, before initializing my TestCase class.
It works well for me ...
Is it possible, in general, to call an interactive function from init.el, if it's parameters are known?
Let me give a concrete example: In the sql package, there is a interactive function sql-connect.
When invoked as
M-x sql-connect
it asks for Connection in the minibuffer. Answering
my-mysql-localhost-connection1
opens an SQL buffer with mysql prompt which it what I want.
I would like to start the connection in a SQL buffer on Emacs startup. But adding, in my init.el:
(sql-connect 'my-mysql-localhost-connection1)
does not do anything. Is what I am trying to achieve possible in this case, and for a general interactive function (which parameters are known)
Thanks
In general:
Yes, and you can use repeat-complex-command (C-xM-:) after the interactive call to find out what the arguments ended up looking like. This is a useful approach to remember, because sometimes there are hidden manipulations in an interactive form which can transform the user's input into something different1.
That doesn't necessarily give you the best arguments to use in a non-interactive call (that will always be dependent on the function in question), but it's probably the best place to start if you're unsure how to translate the one to the other2.
1 align-regexp is a good example of this.
2 Assuming that you've at least read the docstring for the function in question -- it's not uncommon for a given interactive command to be the wrong thing to call in a non-interactive context, and the function help is usually good enough to point this out.
The answer to your general question is yes: you can invoke an interactive function from code, instead of using M-x.
Wrt your more specific question:
You should not need to call the function interactively (i.e., no need to use call-interactively) unless for some reason you really want to invoke it interactively for some reason (e.g., to prompt the user). ;-)
Just call it by supplying the necessary arguments, and you should be OK. IOW this should work:
(sql-connect 'my-mysql-localhost-connection1)
But the doc says that the CONNECTION arg must define actual connection settings, per sql-connection-alist. Check that my-mysql-localhost-connection1 does follow sql-connection-alist in defining connection settings properly so that the user is not prompted for any login parameters.
I need to determinate which agents and daemons are disabled on my OSX. Each process has plist file with parameters. I assume "Disabled" key is responsible for that. But not all agents/daemons has this value. So if property list doesn't contain this paramater it means it's disabled or enabled? I didn't find any info regarding default value for this item.
Please provide a reference to apple's documentation which proof it.
The "Disabled" keys in each LaunchDaemon file can be overridden by an entry in /private/var/db/launchd.db/com.apple.launchd/overrides.plist, and there's a similar system for LaunchAgents in /private/var/db/launchd.db/com.apple.launchd.peruser.userID/overrides.plist. I don't think Apple has documented this anywhere, which means that you are not expected to interact directly with these files, just use launchctl. It also means they're subject to change (i.e. it didn't always work this way and might change without notice in a later version of OS X). Also, the file for LaunchDaemons is only readable by root.
If I want to see whether option X is enabled for host Y, I can:
scan /etc/ssh/ssh_config for a section matching that host
Look for a setting for that option
Do the same for ~/.ssh/config
Look in the documentation for the default value of that option.
However that's kind of a lot of steps and the client program itself does all of these things when it starts up, so it seems like there must be a way to just get the client to provide the answer. Is there?