To check if a directory exists in a shell script, you can use the following:
if [ -d "$DIRECTORY" ]; then
# Control will enter here if $DIRECTORY exists.
fi
Or to check if a directory doesn't exist:
if [ ! -d "$DIRECTORY" ]; then
# Control will enter here if $DIRECTORY doesn't exist.
fi
如果已經在ECLIPSE中CLONE了GIT的項目，這時當GIT中又新建了項目，ECLIPSE無法切換到這新建的項目，解決辦法：
In the Git Repositories view:
- Right-click the repository and choose Fetch from Upstream
- If the new branch will not shown up below Branches/Remote Tracking, you have to configure fetch:
- Right-click the fetch node below Remotes/origin and choose Configure Fetch...
- In the Configure Fetch make sure there is only the single Ref mapping (assuming the remote is named
origin) +refs/heads/*:refs/remotes/origin/*:
這時再次Fetch from upstream，則新建的項目再次重現：Git Repositories View-->Branches-->Remote Checking中。
雙擊新的分支，選：Check out as New Local Branch即可。
https://stackoverflow.com/questions/47390703/how-do-i-get-a-new-branch-to-show-up-in-eclipse-git-remote-tracking/47391183
先在主控機執行ssh-keygen，再向被控機傳輸key，
ssh-copy-id -i ~/.ssh/id_rsa.pub user1@ip
樣例腳本transfer-artemis.sh如下：
#!/bin/bash
loop_server(){
for ((i=2; i<=8; i++))
do
ipd=10.10.31.1${i}2
echo ${ipd}
$1 ${ipd}
done
for ((i=1; i<=2; i++))
do
ipd=10.20.31.1${i}2
echo ${ipd}
$1 ${ipd}
done
}
start_artemis_cmd(){
echo "ssh user1@${1} '/opt/myapp/artemis/apache-artemis-2.15.0/instance/bin/artemis-service start'"
ssh user1@${1} '/opt/myapp/artemis/apache-artemis-2.15.0/instance/bin/artemis-service start'
}
stop_artemis_cmd(){
echo "ssh user1@${1} '/opt/myapp/apache-activemq-5.15.10/bin/activemq stop'"
echo "ssh user1@${1} '/opt/myapp/artemis/apache-artemis-2.15.0/instance/bin/artemis-service stop'"
ssh user1@${1} '/opt/myapp/apache-activemq-5.15.10/bin/activemq stop'
ssh user1@${1} '/opt/myapp/artemis/apache-artemis-2.15.0/instance/bin/artemis-service stop'
}
scp_artemis_cmd(){
echo "ssh user1@${1} 'rm -rf /opt/myapp/artemis'"
echo "scp -r /opt/myapp/artemis user1@${1}:/opt/myapp/"
ssh user1@${1} 'rm -rf /opt/myapp/artemis'
scp -r /opt/myapp/artemis user1@${1}:/opt/myapp/
}
stop_artemis(){
loop_server stop_artemis_cmd
}
start_artemis(){
loop_server start_artemis_cmd
}
scp_artemis(){
loop_server scp_artemis_cmd
}
#start_artemis "Hello start_artemis"
$1
執行命令：
./transfer-artemis.sh start_artemis
pom.xml:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.1.1</version>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
<configuration>
<descriptors>
<descriptor>src/main/assembly/descriptor.xml</descriptor>
</descriptors>
<archiverConfig>
<directoryMode>0755</directoryMode>
<defaultDirectoryMode>0755</defaultDirectoryMode>
<fileMode>0644</fileMode>
</archiverConfig>
</configuration>
</plugin>
src/main/assembly/descriptor.xml，在此文件覆蓋：
<fileSets>
<fileSet>
<directory>src/conf</directory>
<outputDirectory>conf</outputDirectory>
<fileMode>0600</fileMode>
<directoryMode>0700</directoryMode>
</fileSet>
<fileSet>
<directory>src/db</directory>
<outputDirectory>db</outputDirectory>
</fileSet>
<fileSet>
<directory>src/bin</directory>
<outputDirectory>bin</outputDirectory>
<fileMode>0755</fileMode>
</fileSet>
nohup命令及其輸出文件
nohup命令：如果你正在運行一個進程，而且你覺得在退出帳戶時該進程還不會結束，那么可以使用nohup命令。該命令可以在你退出帳戶/關閉終端之后繼續運行相應的進程。nohup就是不掛起的意思( n ohang up)。
一般都是在linux下nohup格式：
nohup command
或者
nohup command &
這之間的差別是帶&的命令行，即使terminal（終端）關閉，或者電腦死機程序依然運行（前提是你把程序遞交到服務器上）；
它把標準輸出（STDOUT）和標準錯誤（STDERR）結果輸出到nohup.txt文件這個看似很方便，但是當輸出很大的時候，nohup.txt文件會非常大，或者多個后臺命令的時候大家都會輸出到nohup.txt文件，不利于查找結果和調試程序。
所以能夠重定向輸出會非常方便。下面要介紹標準輸出，標準輸入 和標準錯誤了。
其實我們一直都在用，只是沒有注意到，
比如
>./command.sh > output
#這其中的>就是標準輸出符號，其實是 1>output 的縮寫
>./command.sh 2> output
＃這里的2>就是將標準錯誤輸出到output文件里。
而0< 則是標準輸入了。
下面步入正題，重定向后臺命令
>nohup ./command.sh > output 2>&1 &
解釋：前面的nohup 和后面的&我想大家都能明白了把。
主要是中間的 2>&1的意思
這個意思是把標準錯誤（2）重定向到標準輸出中（1），而標準輸出又導入文件output里面， www.2cto.com
所以結果是標準錯誤和標準輸出都導入文件output里面了。
至于為什么需要將標準錯誤重定向到標準輸出的原因，那就歸結為標準錯誤沒有緩沖區，而stdout有。
這就會導致 >output 2>output 文件output被兩次打開，而stdout和stderr將會競爭覆蓋，這肯定不是我門想要的.
這就是為什么有人會寫成：
nohup ./command.sh >output 2>output
出錯的原因了
##########################
最后談一下/dev/null文件的作用
這是一個無底洞，任何東西都可以定向到這里，但是卻無法打開。
所以一般很大的stdou和stderr當你不關心的時候可以利用stdout和stderr定向到這里
>./command.sh >/dev/null 2>&1
When we want to do something later in our Java code, we often turn to the ScheduledExecutorService. This class has a method called schedule(), and we can pass it some code to be run later like this:
ScheduledExecutorService executor =
Executors.newScheduledThreadPool(4);
executor.schedule(
() -> {System.out.println("..later");},
1,
TimeUnit.SECONDS
);
System.out.println("do
");
// (Don't forget to shut down the executor later)The above code prints “do…” and then one second later it prints “…later”.
We can even write code that does some work and returns a result in a similar way:
// (Make the executor as above.)
ScheduledFuture future = executor.schedule(
() -> 10 + 25, 1, TimeUnit.SECONDS);
System.out.println("answer=" + future.get())
The above code prints “answer=35”. When we call get() it blocks waiting for the scheduler to run the task and mark the ScheduledFuture as complete, and then returns the answer to the sum (10 + 25) when it is ready.
This is all very well, but you may note that the Future returned from schedule() is a ScheduledFuture, and a ScheduledFuture is not a CompletableFuture.
Why do you care? Well, you might care if you want to do something after the scheduled task is completed. Of course, you can call get(), and block, and then do something, but if you want to react asynchronously without blocking, this won’t work.
The normal way to run some code after a Future has completed is to call one of the “then*” or “when*” methods on the Future, but these methods are only available on CompletableFuture, not ScheduledFuture.
Never fear, we have figured this out for you. We present a small wrapper for schedule that transforms your ScheduledFuture into a CompletableFuture. Here’s how to use it:
CompletableFuture<Integer> future =
ScheduledCompletable.schedule(
executor,
() -> 10 + 25,
1,
TimeUnit.SECONDS
);
future.thenAccept(
answer -> {System.out.println(answer);}
);
System.out.println("Answer coming
")
The above code prints “Answer coming…” and then “35”, so we can see that we don’t block the main thread waiting for the answer to come back.
So far, we have scheduled a synchronous task to run in the background after a delay, and wrapped its result in a CompletableFuture to allow us to chain more tasks after it.
In fact, what we often want to do is schedule a delayed task that is itself asynchronous, and already returns a CompletableFuture. In this case it feels particularly natural to get the result back as a CompletableFuture, but with the current ScheduledExecutorService interface we can’t easily do it.
It’s OK, we’ve figured that out too:
Supplier<CompletableFuture<Integer>> asyncTask = () ->
CompletableFuture.completedFuture(10 + 25);
CompletableFuture<Integer> future =
ScheduledCompletable.scheduleAsync(
executor, asyncTask, 1, TimeUnit.SECONDS);
future.thenAccept(
answer -> {System.out.println(answer);}
);
System.out.println("Answer coming
")
The above code prints “Answer coming…” and then “35”, so we can see that our existing asynchronous task was scheduled in the background, and we didn’t have to block the main thread waiting for it. Also, under the hood, we are not blocking the ScheduledExecutorService‘s thread (from its pool) while the async task is running – that task just runs in whatever thread it was assigned when it was created. (Note: in our example we don’t really run an async task at all, but just immediately return a completed Future, but this does work for real async tasks.)
I know you’re wondering how we achieved all this. First, here’s how we run a simple blocking task in the background and wrap it in a CompletableFuture:
public static <T> CompletableFuture<T> schedule(
ScheduledExecutorService executor,
Supplier<T> command,
long delay,
TimeUnit unit
) {
CompletableFuture<T> completableFuture = new CompletableFuture<>();
executor.schedule(
(() -> {
try {
return completableFuture.complete(command.get());
} catch (Throwable t) {
return completableFuture.completeExceptionally(t);
}
}),
delay,
unit
);
return completableFuture;
}
And here’s how we delay execution of an async task but still return its result in a CompletableFuture:
public static <T> CompletableFuture<T> scheduleAsync(
ScheduledExecutorService executor,
Supplier<CompletableFuture<T>> command,
long delay,
TimeUnit unit
) {
CompletableFuture<T> completableFuture = new CompletableFuture<>();
executor.schedule(
(() -> {
command.get().thenAccept(
t -> {completableFuture.complete(t);}
)
.exceptionally(
t -> {completableFuture.completeExceptionally(t);return null;}
);
}),
delay,
unit
);
return completableFuture;
}
Note that this should all work to run methods like exceptionally(), thenAccept(), whenComplete() etc.
Feedback and improvements welcome!
https://www.artificialworlds.net/blog/2019/04/05/scheduling-a-task-in-java-within-a-completablefuture/