<div dir="ltr">In the assignment spec, it mentions that the user can do the following:<div><font face="monospace, monospace">export EC2_BACKUP_FLAGS_SSH=&quot;-i ~/.ssh/ec2-key&quot;<br></font><br>However, from trying this, I cannot get this to work, in that sh will not expand the tilde, so I get:<br><font face="monospace, monospace">Identity file ~/.ssh/ec2-key not accessible: No such file or directory</font><br>(despite the key being there)<br><br>If I change it to be <br><font face="monospace, monospace">export EC2_BACKUP_FLAGS_SSH=&quot;-i /root/.ssh/ec2-key&quot;</font><br>It works fine. <br><br>I thought it maybe had to do with having quotes around the variable name </div><div>(I.E. ssh &quot;$EC2_BACKUP_FLAGS_SSH&quot; ...), but getting rid of the quotes did not fix the issue.</div><div><br>Is there any special way to use the EC2_BACKUP_FLAGS_SSH so that the tilde expansion</div><div> happens, or would this just be considered bad input on the user&#39;s end?<br><br>-Justin<br><br><br>On Wed, Apr 3, 2019 at 11:42 PM Jan Schaumann &lt;<a href="mailto:jschauma@stevens.edu">jschauma@stevens.edu</a>&gt; wrote:<br>&gt;<br>&gt; Justin Barish &lt;<a href="mailto:jbarish@stevens.edu">jbarish@stevens.edu</a>&gt; wrote:<br>&gt;<br>&gt; &gt; Since we should check the return code of all functions for failure, how<br>&gt; &gt; should this be handled, since the above causes a return code of 1, as does<br>&gt; &gt; other possible failures? Would a correct answer be to just ignore the<br>&gt; &gt; return value of du, and do checks (such as the existence of the directory)<br>&gt; &gt; separately?<br>&gt;<br>&gt; Consider what the user would want and most likely expect.  If I&#39;m trying<br>&gt; to backup a directory, but don&#39;t have permissions to access some<br>&gt; subdirectories deep within the hierarchy, would I want:<br>&gt;<br>&gt; - the backup to abort, saying that it can&#39;t read all the files?<br>&gt;<br>&gt; - the backup to continue as best as it can, but let me know that some<br>&gt;   directories could not be backed up?<br>&gt;<br>&gt; - to silently ignore the error and thus give me the impression that all<br>&gt;   data was backed up?<br>&gt;<br>&gt; I think the third option is not acceptable, but for the first two an<br>&gt; argument can be made either way.  Your choice here then dictates how you<br>&gt; want to handle the other special cases, although I suspect some initial<br>&gt; sanity checking on the arguments given prior to invoking du(1) would<br>&gt; likely make sense.<br>&gt;<br>&gt; &gt; Also, should we have du count filesystem mount points, or ignore them (-x<br>&gt; &gt; flag)?<br>&gt;<br>&gt; By convention, Unix tools require a flag to be instructed not to cross<br>&gt; mountpoints, so the default is to be mount point agnostic.  Your tool<br>&gt; should follow that convention.  (A future iteration could conceivably<br>&gt; add an option to not traverse mount points, but we don&#39;t need that here,<br>&gt; I think.)<br>&gt;<br>&gt; -Jan<br>&gt; _______________________________________________<br>&gt; cs615asa mailing list<br>&gt; <a href="mailto:cs615asa@lists.stevens.edu">cs615asa@lists.stevens.edu</a><br>&gt; <a href="https://lists.stevens.edu/mailman/listinfo/cs615asa">https://lists.stevens.edu/mailman/listinfo/cs615asa</a></div></div>