--- a/relpipe-data/examples-tr-sqlite-custom-version.xml	Fri Nov 29 20:03:12 2019 +0100
+++ b/relpipe-data/examples-tr-sqlite-custom-version.xml	Wed Dec 04 10:57:28 2019 +0100
@@ -104,13 +104,21 @@
 		
 		<p>That would not be possible with older versions of the SQLite library – as we can check by unsetting the <code>LD_PRELOAD</code> variable:</p>
 		<m:pre jazyk="bash"><![CDATA[unset LD_PRELOAD]]></m:pre>
-		<p>Which returns us to the previous state where SQLite from our distribution was used. And the calling the same SQL query leads to an error.</p>
+		<p>Which returns us to the previous state where SQLite from our distribution was used. And then calling the same SQL query leads to an error.</p>
 		
 		<p>
 			The <code>LD_PRELOAD</code> hack can be used with any other software – it is not specific to <m:name/>.
 			Another example is the <a href="https://mouse.globalcode.info/v_0/spacenav-hack.xhtml">Spacenav Hack</a>  which bridges/translates two APIs of a library.
 		</p>
-
+		
+		<p>
+			n.b. if we do <code>export LD_PRELOAD</code> it will affect all programs started from given shell session
+			and if we even put it in our <code>.bashrc</code>, it will affect all Bash sessions started later and programs started from them.
+			Which might not be a desired behavior. So sometimes it is better to set the <code>LD_PRELOAD</code> variable only for a single command, not globally.
+			This can be done through a custom wrapper script or an alias:
+		</p>
+		<m:pre jazyk="bash"><![CDATA[alias relpipe-tr-sql='LD_PRELOAD=~/src/sqlite/sqlite-autoconf-3300100/.libs/libsqlite3.so.0 relpipe-tr-sql']]></m:pre>
+		<p>We can safely put this this line into our <code>.bashrc</code> without affecting any other software.</p>
 				
 		<h2>ABI compatibility</h2>