<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 7 de jan. de 2021 às 14:05, Alexandre Torres Porres <<a href="mailto:porres@gmail.com">porres@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Em qui., 7 de jan. de 2021 às 09:38, alfonso santimone <<a href="mailto:alfonso.santimone@gmail.com" target="_blank">alfonso.santimone@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Works fine here on Win10 64bit. Thanks!<div>Only little thing to watch out is that [ fluid~ ] is the name of another external contained in the (very nice) ceammc library.</div><div>Obviously calling this by [fluid~/fluid~] just works.</div></div></blockquote><div><br></div><div>funny, I tested [declare -path fluid~] and that <b>DOESN'T WORK </b>if I have ceammc in the start up. Meaning it'll just load fluid~ from ceammc. Now, I did not expect that... still thinking about it, but it feels like it shouldn't be that way.  </div></div></div></blockquote><div><br></div><div>On the other hand, having [declare -lib fluid~] works by superseding the priority of 'ceammc' in startup! So I'm using this instead (cause fluid~/fluid~ just looks terrible!).</div><div><br></div><div>And it seems once you load a binary in startup, it stays there forever and has priority over search paths. So I need to document this.</div></div></div>