Re: How to overwrite a symbolic link?
Le 07/05/2010 16:02, Peng Yu a écrit : > I can copy the whole > directory and then modify one file in the newly copied N files. But > I'll lose track of which file has been changed later on, which is > important to me. You will not lose track of the changed files: just run a recursive diff comparing the old and new directories and you will see what was/has changed (this is actually the poor man's version control system). > Suppose I have N files in a directory that does some job. Lets say M > ( files (say, there are a number of programs, each takes some of the M > files to generate some of the N-M files). > [...] > Instead, I'd rather create symbolic link for all the N-M-1 primary > files but copy only one remaining file and modify it. Remember, I > can't tell which are primary files and which are derived files. So I > can not do so. > > One solution is create symbolic link to N-1 files as long as I can > overload '>' and '>>' and the open file function call. So you are really trying to re-invent some copy-on-write/versioning file system by hacking symbolic links and redirections. This looks like a lot of pain. You'd better start by looking at existing solutions; even if none is ideal for your case, you would at least leverage the existing knowledge and experience in this field instead of starting from zero. > Let me know if you have any thought on solving this problem. Since you are using the wrong tool for the job I am afraid you are going to be rather alone on this road. Cheers, Marc
Re: Standard .bashrc needs a minor fix
On Sat, May 08, 2010 at 08:42:02AM -0800, Ken Irving wrote: > bash(1) (v4.1) includes: > > OPTIONS > ... > -iIf the -i option is present, the shell is interactive. > > and > > INVOCATION > ... > PS1 is set and $- includes i if bash is interactive, allowing > a shell script or a startup file to test this state. > > The latter statement is ambiguous, possibly suggesting that PS1 should > also be checked to test for an interactive shell. I read it to mean, "If bash is interactive, then $- will include i and PS1 will be set." I interpret the second part as a description of common practice, which is not necessarily the same as *best* practice. (Or a justification of why the shell acts as it does -- "because people expect it to be this way".) PS1 might be set regardless of whether the shell is interactive or not, simply because it's often exported to the environment. I think that in the end it's all a matter of what *you* want to test for. Consider the commands that you're trying to run (or prevent from running), and what they do. Consider the circumstances when they're desired, or undesired, or safe, or unsafe; and write the scripts accordingly.
Re: How to overwrite a symbolic link?
On Mon, May 10, 2010 at 6:59 AM, Marc Herbert wrote: > Le 07/05/2010 16:02, Peng Yu a écrit : >> I can copy the whole >> directory and then modify one file in the newly copied N files. But >> I'll lose track of which file has been changed later on, which is >> important to me. > > You will not lose track of the changed files: just run a recursive > diff comparing the old and new directories and you will see what > was/has changed (this is actually the poor man's version control > system). If I have X similar directories that are resulted from the copying and modifying in the above, I will end up X*(X-1) comparisons. And it is still hard to figure out the lineage of these X directories from these X*(X-1) comparisons (because I need to compare diffs of diffs). Therefore, I think that this is not a viable solution. >> Suppose I have N files in a directory that does some job. Lets say M >> (> files (say, there are a number of programs, each takes some of the M >> files to generate some of the N-M files). >> [...] >> Instead, I'd rather create symbolic link for all the N-M-1 primary >> files but copy only one remaining file and modify it. Remember, I >> can't tell which are primary files and which are derived files. So I >> can not do so. >> >> One solution is create symbolic link to N-1 files as long as I can >> overload '>' and '>>' and the open file function call. > > So you are really trying to re-invent some copy-on-write/versioning > file system by hacking symbolic links and redirections. This looks > like a lot of pain. You'd better start by looking at existing > solutions; even if none is ideal for your case, you would at least > leverage the existing knowledge and experience in this field instead > of starting from zero. http://en.wikipedia.org/wiki/Versioning_file_system http://en.wikipedia.org/wiki/Ext3cow I'm trying to understand how versioning and copy-on-write are relevant to my cases. But I don't think that they are really relevant to my cases. The closest file system that I have used is snapshot (I don't know the exact technical term, but I remember there is a '.snapshot' directory in my home, where I can find previous 1 hour, 4 hours, 1 day and 1week versions of my home directory). Please correct me if I'm wrong. These versioning file systems automatically keep different versions (modified at different time) of the same file, and doesn't allow users to choose which versions to keep and which version not to keep. This will end up to many versions that are actually not useful and it would a pain to look for the actual useful versions. Also I need the same file appear in two different directories. I think that these versioning systems may not help me on this aspect unless I use symbolic links. Therefore, the solution to my particular problem is still in hacking symbolic link. >> Let me know if you have any thought on solving this problem. > > Since you are using the wrong tool for the job I am afraid you are > going to be rather alone on this road. For right now, I think that the best solution is, instead of reloading >, >>, and related system calls, to test symbolic link and rm it and then write a new file with the same name. The trick of _ function by Dennis is useful. -- Regards, Peng
Re: How to overwrite a symbolic link?
Peng Yu wrote: > Marc Herbert wrote: > > So you are really trying to re-invent some copy-on-write/versioning > > file system by hacking symbolic links and redirections. This looks > > like a lot of pain. You'd better start by looking at existing > > solutions; even if none is ideal for your case, you would at least > > leverage the existing knowledge and experience in this field instead > > of starting from zero. > > http://en.wikipedia.org/wiki/Versioning_file_system > http://en.wikipedia.org/wiki/Ext3cow > > I'm trying to understand how versioning and copy-on-write are relevant > to my cases. But I don't think that they are really relevant to my > cases. Let me explain how I am reading it. You are making a "copy" of some files by creating symlinks in the new location that are pointing to the old location. Then when you write to the new location you are trying to break the symlink and write a new file in the new location. That process is exactly the process of a copy-on-write filesystem. In copy-on-write any write to the new location creates a new copy instead of overwriting the old. But it is done at the filesystem level. All writes of any type cause this to happy. > The closest file system that I have used is snapshot (I don't know the > exact technical term, but I remember there is a '.snapshot' directory > in my home, where I can find previous 1 hour, 4 hours, 1 day and 1week > versions of my home directory). Your home directory is on NFS and very likely being served by an EMC device. It is making time based snapshots. That isn't the same thing. > Please correct me if I'm wrong. These versioning file systems > automatically keep different versions (modified at different time) of No. Copy-on-write filesystems automatically make a copy of your file when you write to it. Bob
^K should go to next history item
^P^P^P^P^K^K^K^K or at least ^P^P^P^P^A^K^A^K^A^K^A^K should kill each line out of the history. Instead we need to do more steps: ^P^P^P^P^A^K^N^A^K^N^A^K^N^A^K .
