Hi Phil,
I started working down that path, however once it does the expansion, everything ends up in one argument (argv[1])
distributed_address_pipe transport entered
direct command:
argv[0] = /usr/local/cpanel/bin/remote_mail_exec
argv[1] = ${substr{1}{$address_pipe}}
direct command after expansion:
argv[0] = /usr/local/cpanel/bin/remote_mail_exec
argv[1] = /usr/local/cpanel/bin/remote_mail_exec_test -p -d
From transport.c
On line 2026 its going to just push everything into one argument.
It looks like $pipe_addresses is handled as a special case. I could just make $address_pipe a special case (just sounds icky though) and strip of the leading |, however I'm not familiar with code to fully understand the implications (it starts to make the use_wrapper idea look better).
Would you be so kind as to provide some guidance?
Thanks
-Nick
1979 /* Handle special fudge for passing an address list */
1980
1981 if (addr != NULL &&
1982 (Ustrcmp(argv[i], "$pipe_addresses") == 0 ||
1983 Ustrcmp(argv[i], "${pipe_addresses}") == 0))
1984 {
1985 int additional;
1986
1987 if (argcount + address_count - 1 > max_args)
1988 {
1989 addr->transport_return = FAIL;
1990 addr->message = string_sprintf("Too many arguments to command \"%s\" "
1991 "in %s", cmd, etext);
1992 return FALSE;
1993 }
1994
1995 additional = address_count - 1;
1996 if (additional > 0)
1997 memmove(argv + i + 1 + additional, argv + i + 1,
1998 (argcount - i)*sizeof(uschar *));
1999
2000 for (ad = addr; ad != NULL; ad = ad->next) argv[i++] = ad->address;
2001 i--;
2002 }
2003
2004 /* Handle normal expansion string */
2005
2006 else
2007 {
2008 uschar *expanded_arg;
2009 enable_dollar_recipients = allow_dollar_recipients;
2010 expanded_arg = expand_string(argv[i]);
2011 enable_dollar_recipients = FALSE;
2012
2013 if (expanded_arg == NULL)
2014 {
2015 uschar *msg = string_sprintf("Expansion of \"%s\" "
2016 "from command \"%s\" in %s failed: %s",
2017 argv[i], cmd, etext, expand_string_message);
2018 if (addr != NULL)
2019 {
2020 addr->transport_return = expand_failed;
2021 addr->message = msg;
2022 }
2023 else *errptr = msg;
2024 return FALSE;
2025 }
2026 argv[i] = expanded_arg;
2027 }
2028 }
On Mar 29, 2013, at 9:35 PM, Phil Pennock <pdp@???> wrote:
> On 2013-03-29 at 17:19 -1000, J. Nick Koston wrote:
>> Thanks for the quick response. Supporting arbitrary commands being forcibly
>> wrapped when they come from a router is exactly what we are needing to accomplish.
>>
>> I would be happy to attempt to cook up a patch to implement "override_router" and push it to github, or wherever is best?
>
> Posting here is good. If you're happiest with a GitHub PR, I can make
> that work, but it's more of an exception -- we take changes as
> available, rather than _insisting_ people do things our way. But we
> _prefer_ exim-dev.
>
> Er, there's a recent example to the contrary, but that's because Todd
> has a mega-branch to merge, with many patches, and we're trying out
> GitHub's tools as a way to manage it. Maybe. It's not
> precedent-setting, though. (I think?)
>
>>> override_router
>>> command = prefix -args -- $address_pipe
>>
>> Thats exactly what we need. The commands are coming in from filter filer.
>
> It would need testing to be sure, but this should just be a matter of
> changing src/transports/pipe.{h,c} to add a boolean option and then in
> pipe_transport_entry() around line 570 add in support for this new
> boolean.
>
> It looks as though $address_pipe includes the leading "|" symbol, but
> I'm not 100% on this from looking at the code; is that likely to be an
> issue?
>
> -Phil
>
