<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 July 2014 15:58, Sjoerd de Vries <span dir="ltr"><<a href="mailto:sjdv1982@gmail.com" target="_blank">sjdv1982@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_extra">Thank you for your response, but I am a bit sad to hear this. Now that the sh profile is deleted, is system-shell-replacement no longer within the scope of IPython, ?</div></blockquote><div><br></div>

<div>As Fernando indicated, that's never really been IPython's aim. Of course we like seeing what people build with IPython, but that use case isn't something we especially support.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_extra"></div><div class="gmail_extra">In addition, the extension would manipulate input_transformer_manager.logical_line_transforms, so that the standard input transformers "escaped_commands" and  "assign_from_system"  will be overruled. This is a bit rude, but it should work.<br>

</div></blockquote><div><br></div><div>That's OK, the input transformation API is there to allow this kind of extension. This is, however, a 'consenting adults' klnd of API - it's entirely possible to break IPython syntax with this, so it's up to you to ensure that things work together.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">
</div><div class="gmail_extra"></div><div class="gmail_extra">However, it would still require the following modifications to the IPython core:</div><div>- Support for evaluators, and the use of AliasEvaluator by %alias (to allow delayed evaluation) <br>

</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra">- A hook to change the %alias formatter class from DollarFormatter (to allow customized variable substitution)</div><div class="gmail_extra">- A hook in FullEvalFormatter._vformat to be triggered on certain "conversion" values (for converters)<br>

</div></blockquote><div><br></div><div>I think the simplest approach to this is something we've been talking about for a while - we shouldn't call var_expand for all magic commands. The obvious answer to this would be to not do it for any magics, and have the magics that want it call it internally, but we've hesitated because we think var_expand makes sense for the majority of magics, and it seems awkward to make them all call it for the sake of a few that don't. An alternative would be to decorate magic function definitions in some way to indicate that var_expand *shouldn't* be called (and leave calling them as the default).<br>

<br></div><div>Other than that, magics just get the raw string, so you should be able to do whatever you want with that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_extra">
</div><div class="gmail_extra">- Additional optional arguments to interactiveshell methods "getoutput", "system_piped" and "system_raw" (for variable substitution and stderr capture)</div></blockquote>

<div><br></div><div>I think an argument for stderr capture makes sense. For controlling variable substitution, it might be easier to go down a level, to the (similarly named) functions which they call after doing var_expand.<br>

<br></div><div>Thomas <br></div></div><br></div><div class="gmail_extra"><br></div></div>