1、将文件checkout到本地目录
svn checkout path（path是服务器上的目录）
例如：svn checkout svn://192.168.1.1/pro/domain
简写：svn co
2、往版本库中添加新的文件
svn add file
例如：svn add test.php(添加test.php)
svn add *.php(添加当前目录下所有的php文件)
3、将改动的文件提交到版本库
svn commit -m “LogMessage” [-N] [--no-unlock] PATH
(如果选择了保持锁，就使用-no-unlock开关)
例如：svn commit -m “add test file for my test” test.php
简写：svn ci
Remember FIFOs? Remember how they can only send data in one direction, just like a Pipes? Wouldn’t it be grand if you could send data in both directions like you can with a socket?
Well, hope no longer, because the answer is here: Unix Domain Sockets! In case you’re still wondering what a socket is, well, it’s a two-way communications pipe, which can be used to communicate in a wide variety of domains. One of the most common domains sockets communicate over is the Internet, but we won’t discuss that here. We will, however, be talking about sockets in the Unix domain; that is, sockets that can be used between processes on the same Unix system.
Unix sockets use many of the same function calls that Internet sockets do, and I won’t be describing all of the calls I use in detail within this document. If the description of a certain call is too vague (or if you just want to learn more about Internet sockets anyway), please see Beej’s Guide to Network Programming Using Internet Sockets for more detailed information.
Like I said before, Unix sockets are just like two-way FIFOs. However, all data communication will be taking place through the sockets interface, instead of through the file interface. Although Unix sockets are a special file in the file system (just like FIFOs), you won’t be using open() and read()–you’ll be using socket(), bind(), recv(), etc.
When programming with sockets, you’ll usually create server and client programs. The server will sit listening for incoming connections from clients and handle them. This is very similar to the situation that exists with Internet sockets, but with some fine differences.
For instance, when describing which Unix socket you want to use (that is, the path to the special file that is the socket), you use a struct sockaddr_un, which has the following fields:
struct sockaddr_un {
unsigned short sun_family; /* AF_UNIX */
char sun_path[108];
}
This is the structure you will be passing to the bind() function, which associates a socket descriptor (a file descriptor) with a certain file (the name for which is in the sun_path field).
Without going into too much detail, I’ll outline the steps a server program usually has to go through to do it’s thing. While I’m at it, I’ll be trying to implement an "echo server" which just echos back everything it gets on the socket.
Here are the server steps:
unsigned int s, s2;
struct sockaddr_un local, remote;
int len;
s = socket(AF_UNIX, SOCK_STREAM, 0);
The second argument, SOCK_STREAM, tells socket() to create a stream socket. Yes, datagram sockets (SOCK_DGRAM) are supported in the Unix domain, but I’m only going to cover stream sockets here. For the curious, see Beej’s Guide to Network Programming for a good description of unconnected datagram sockets that applies perfectly well to Unix sockets. The only thing that changes is that you’re now using astruct sockaddr_un instead of a struct sockaddr_in.
One more note: all these calls return -1 on error and set the global variable errno to reflect whatever went wrong. Be sure to do you error checking.
local.sun_family = AF_UNIX; /* local is declared before socket() ^ */
local.sun_path = "/home/beej/mysocket";
unlink(local.sun_path);
len = strlen(local.sun_path) + sizeof(local.sun_family);
bind(s, (struct sockaddr *)&local, len);
This associates the socket descriptor "s" with the Unix socket address "/home/beej/mysocket". Notice that we called unlink() before bind() to remove the socket if it already exists. You will get an EINVAL error if the file is already there.
listen(s, 5);
The second argument, 5, is the number of incoming connections that can be queued before you call accept(), below. If there are this many connections waiting to be accepted, additional clients will generate the error ECONNREFUSED.
len = sizeof(struct sockaddr_un);
s2 = accept(s, &remote, &len);
When accept() returns, the remote variable will be filled with the remote side’s struct sockaddr_un, and len will be set to its length. The descriptor s2 is connected to the client, and is ready for send() and recv(), as described in the Network Programming Guide.
while (len = recv(s2, &buf, 100, 0), len > 0)
send(s2, &buf, len, 0);
/* loop back to accept() from here */
With all that said, here is some source for an echoing server, echos.c. All it does is wait for a connection on a Unix socket (named, in this case, "echo_socket").
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#define SOCK_PATH "echo_socket"
int main(void)
{
int s, s2, t, len;
struct sockaddr_un local, remote;
char str[100];
if ((s = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
perror("socket");
exit(1);
}
local.sun_family = AF_UNIX;
strcpy(local.sun_path, SOCK_PATH);
unlink(local.sun_path);
len = strlen(local.sun_path) + sizeof(local.sun_family);
if (bind(s, (struct sockaddr *)&local, len) == -1) {
perror("bind");
exit(1);
}
if (listen(s, 5) == -1) {
perror("listen");
exit(1);
}
for(;;) {
int done, n;
printf("Waiting for a connection...\n");
t = sizeof(remote);
if ((s2 = accept(s, (struct sockaddr *)&remote, &t)) == -1) {
perror("accept");
exit(1);
}
printf("Connected.\n");
done = 0;
do {
n = recv(s2, str, 100, 0);
if (n <= 0) {
if (n < 0) perror("recv");
done = 1;
}
if (!done)
if (send(s2, str, n, 0) < 0) {
perror("send");
done = 1;
}
} while (!done);
close(s2);
}
return 0;
}
As you can see, all the aforementioned steps are included in this program: call socket(), call bind(), call listen(), call accept(), and do some network send()s and recv()s.
There needs to be a program to talk to the above server, right? Except with the client, it’s a lot easier because you don’t have to do any pesky listen()ing or accept()ing. Here are the steps:
How about code to talk to the echo server, above? No sweat, friends, here is echoc.c:
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#define SOCK_PATH "echo_socket"
int main(void)
{
int s, t, len;
struct sockaddr_un remote;
char str[100];
if ((s = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
perror("socket");
exit(1);
}
printf("Trying to connect...\n");
remote.sun_family = AF_UNIX;
strcpy(remote.sun_path, SOCK_PATH);
len = strlen(remote.sun_path) + sizeof(remote.sun_family);
if (connect(s, (struct sockaddr *)&remote, len) == -1) {
perror("connect");
exit(1);
}
printf("Connected.\n");
while(printf("> "), fgets(str, 100, stdin), !feof(stdin)) {
if (send(s, str, strlen(str), 0) == -1) {
perror("send");
exit(1);
}
if ((t=recv(s, str, 100, 0)) > 0) {
str[t] = '\0';
printf("echo> %s", str);
} else {
if (t < 0) perror("recv");
else printf("Server closed connection\n");
exit(1);
}
}
close(s);
return 0;
}
In the client code, of course you’ll notice that there are only a few system calls used to set things up: socket() and connect(). Since the client isn’t going to be accept()ing any incoming connections, there’s no need for it to listen(). Of course, the client still uses send() and recv() for transferring data. That about sums it up.
What if you wanted a pipe(), but you wanted to use a single pipe to send and recieve data from both sides? Since pipes are unidirectional (with exceptions in SYSV), you can’t do it! There is a solution, though: use a Unix domain socket, since they can handle bi-directional data.
What a pain, though! Setting up all that code with listen() and connect() and all that just to pass data both ways! But guess what! You don’t have to!
That’s right, there’s a beauty of a system call known as socketpair() this is nice enough to return to you a pair of already connected sockets! No extra work is needed on your part; you can immediately use these socket descriptors for interprocess communication.
For instance, lets set up two processes. The first sends a char to the second, and the second changes the character to uppercase and returns it. Here is some simple code to do just that, called spair.c (with no error checking for clarity):
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
int main(void)
{
int sv[2]; /* the pair of socket descriptors */
char buf; /* for data exchange between processes */
socketpair(AF_UNIX, SOCK_STREAM, 0, sv);
if (!fork()) { /* child */
read(sv[1], &buf, 1);
printf("child: read '%c'\n", buf);
buf = toupper(buf); /* make it uppercase */
write(sv[1], &buf, 1);
printf("child: sent '%c'\n", buf);
} else { /* parent */
write(sv[0], "b", 1);
printf("parent: sent 'b'\n");
read(sv[0], &buf, 1);
printf("parent: read '%c'\n", buf);
}
return 0;
}
Sure, it’s an expensive way to change a character to uppercase, but it’s the fact that you have simple communication going on here that really matters.
One more thing to notice is that socketpair() takes both a domain (AF_UNIX) and socket type (SOCK_STREAM). These can be any legal values at all, depending on which routines in the kernel you want to handle your code, and whether you want stream or datagram sockets. I chose AF_UNIX sockets because this is a Unix sockets document and they’re a bit faster than AF_INET sockets, I hear.
Finally, you might be curious as to why I’m using write() and read() instead of send() and recv(). Well, in short, I was being lazy. See, by using these system calls, I don’t have to enter the flags argument that send() and recv() use, and I always set it to zero anyway. Of course, socket descriptors are just file descriptors like any other, so they respond just fine to many file manipulation system calls.
If you don’t run HPUX, be sure to check your local man pages!
Copyright © 1997 by Brian "Beej" Hall. This guide may be reprinted in any medium provided that its content is not altered, it is presented in its entirety, and this copyright notice remains intact. Contact beej@ecst.csuchico.edu for more information.
关于Linux信号请参见这篇文章http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html
主要是为了理解下面的这段代码：
// Block all signals for background thread.
sigset_t new_mask;
sigfillset(&new_mask);
sigset_t old_mask;
pthread_sigmask(SIG_BLOCK, &new_mask, &old_mask);
// Run server in background thread.
http::server::server s(argv[1], argv[2], argv[3]);
boost::thread t(boost::bind(&http::server::server::run, &s));
// Restore previous signals.
pthread_sigmask(SIG_SETMASK, &old_mask, 0);
// Wait for signal indicating time to shut down.
sigset_t wait_mask;
sigemptyset(&wait_mask);
sigaddset(&wait_mask, SIGINT);
sigaddset(&wait_mask, SIGQUIT);
sigaddset(&wait_mask, SIGTERM);
pthread_sigmask(SIG_BLOCK, &wait_mask, 0);
int sig = 0;
sigwait(&wait_mask, &sig);
其实代码中已经有注释了，写的很明白了。不过，俺一开始不理解的，学习了一下，记录如下。
pthread_sigmask：
int pthread_sigmask(int how, const sigset_t *newmask, sigset_t *oldmask)
设置线程的信号屏蔽码，语义与sigprocmask()相同，但对不允许屏蔽的Cancel信号和不允许响应的Restart信号进行了保护。被屏蔽的信号保存在信号队列中，可由sigpending()函数取出。
How:
SIG_BLOCK: 结果集是当前集合参数集的并集
SIG_UNBLOCK: 结果集是当前集合参数集的差集
SIG_SETMASK: 结果集是由参数集指向的集
sigfillset(sigset_t *set)调用该函数后，set指向的信号集中将包含linux支持的64种信号；
那么第一段代码的意思就是，屏蔽（阻塞）所有的信号，目的是创建下面的业务代码
第二段：
// Restore previous signals.
恢复之前的信号。使用SIG_SETMASK，阻塞结果集由参数指定，即第一段代码执行前的信号集
第三段，Wait for signal indicating time to shut down
设定需要屏蔽（阻塞）的信号，等待，知道信号集中的信号出现。sigwait的第二个参数就是收到的在信号集中存在的信号，可以根据这个参数做出处理。
sigwait() 提供了一种等待信号的到来，以串行的方式从信号队列中取出信号进行处理的机制。sigwait（）只等待函数参数中指定的信号集，即如果新产生的信号不在指定的信号集内，则 sigwait（）继续等待。
ScribeFire
homepage:http://www.scribefire.com/
这是一款以firefox扩展插件形式发布的写博程序。 Scribefire功能是相当强大的，常用的编辑功能，该有的都有了，日志编辑、发布、修改、删除、注解、多媒体，支持离线写作和编辑、所见即所得写 作，还支持TAG，在浏览网页的时候，看到一些好的文字，可以在通过firefox中的右键菜单，直接将文字发布到自己的博客中去。scribefre添 加站点的时候，能自动侦测API协议文件，这样就免去了不用知道这个博客用了什么程序接口也能轻松设置连接博客。Scribefire目前支持 Blogger、LiveJournal、MetaBlogAPI（包括 WordPress，Drupal，和Windows Live Spaces）、Jeeran、Performancing、MovableType、Textpattem、Roller（测试中）
开始使用ScribeFire，到“https://addons.mozilla.org/en-US/firefox/addon/1730”点击“Add to firefox”按钮。
打开etc/fonts/conf.d/49-sansserif.conf，改成下面的就好了。
<fontconfig>
<!–
If the font still has no generic name, add sans-serif
–>
<match target=”pattern”>
<test qual=”all” name=”family” compare=”not_eq”>
<string>文泉驿正黑</string>
</test>
<test qual=”all” name=”family” compare=”not_eq”>
<string>文泉驿正黑</string>
</test>
<test qual=”all” name=”family” compare=”not_eq”>
<string>monospace</string>
</test>
<edit name=”family” mode=”append_last”>
<string>文泉驿正黑</string>
</edit>
</match>
</fontconfig>
1，在redhat系统中可以方便的使用ll列出文件及目录的详细信息，但是ubuntu并没有这个命令，需要使用ls -l来列出详细视图。
2，ls列出的文件应该是不同颜色显示的，但是我的终端上都是一样的颜色，不知道怎么回事，需要ls –color=auto才可以。
我们可以使用alias别名来定义ll命令实现这一功能。
方法为：
编辑~/.bashrc，添加:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\View Source Editor\Editor Name
如果View Source Editor\Editor Name节点没有，则新建。
然后在Editor Name的”默认”里填入新编辑器的路径,如”C:\Program Files\IDM Computer Solutions\UltraEdit-32\Uedit32.exe”
注意：View Source Editor是节点，Editor Name也是节点，修改的是Editor Name节点下的”默认”字段的值
