【Rails】heroku containerをリリース時にアプリがクラッシュする
どうもてぃです。
一ヶ月ほど前に僕もパパになり、可愛い娘の寝顔を見ながら出勤する毎日を過ごしております。
天使すぎてホント癒やされる。
それはさておき、今回はherokuへコンテナデプロイした際に少しハマったので、同じ現象に悩まれてる方へ向けて記事を書きたいと思います。
heroku container
今回始めてheroku containerを使用してみたんですが、めちゃくちゃ簡単でした。
プロジェクトをDockerで作成しているなら是非やってみてください。
ただ、気をつけていないとハマる部分は割とあります。
以下デプロイ手順参考。
個人的にherokuとgoogleはリファレンスが最強だと思ってます。
そんなに難しい英語も書いてないですしね。
はまった現象
heroku containerのデプロイ時に気をつけないといけないのが、デプロイしたいコンテナ以外のコンテナが動いている場合は壊すか止めるかしないとアプリケーションクラッシュの原因になることです。
僕は開発が終わったら毎回コンテナを潰してるので、 docker ps -a
で出てきたものは全て削除してます。
総削除は以下のコマンド。
$ docker rm `docker ps -a -q`
最近はdockerのCUIも増えてきてるのでそれを使うのも有りかもですね。
ちょーっと重いですがvimライクに操作できるので以下を使ってます。
コンテナ削除後、デプロイ手順を踏んで普通にデプロイ。
$ heroku container:push web $ heroku container:release web
大抵はこれで上手く行きますが、アプリケーションを開いたところクラッシュしてました。
以下がログ(heroku logs --tail
)
2019-09-04T01:35:25.823858+00:00 heroku[web.1]: Starting process with command `rails server -b 0.0.0.0` 2019-09-04T01:35:31.697033+00:00 heroku[web.1]: State changed from starting to crashed 2019-09-04T01:35:31.606898+00:00 app[web.1]: A server is already running. Check /myapp/tmp/pids/server.pid. 2019-09-04T01:35:31.608944+00:00 app[web.1]: => Booting Puma 2019-09-04T01:35:31.608946+00:00 app[web.1]: => Rails 5.2.3 application starting in production 2019-09-04T01:35:31.608948+00:00 app[web.1]: => Run `rails server -h` for more startup options 2019-09-04T01:35:31.608949+00:00 app[web.1]: Exiting 2019-09-04T01:35:31.684704+00:00 heroku[web.1]: Process exited with status 1 2019-09-04T01:35:33.527454+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/robots.txt" host=line-bot.herokuapp.com request_id=f2475bec-d670-4f3b-9395-407e57a997c5 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:35:34.134860+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=d61341cf-9cc6-4290-9ece-55689779e7ef fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:22.870909+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=9deb4679-3509-4dbd-bd45-3722609ec387 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:25.542657+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=72fa644f-8a98-4e96-a20b-82e01de4b659 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:28.998503+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=line-bot.herokuapp.com request_id=dd9d8c5e-7f57-4adf-816a-e68782ca8b83 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https 2019-09-04T01:37:29.463016+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/favicon.ico" host=line-bot.herokuapp.com request_id=b0201b8e-efad-41f6-890c-42c4726c3922 fwd="103.5.142.233" dyno= connect= service= status=503 bytes= protocol=https
マイグレーションもやったし、DBもインスタンスも有料化してるし。。。
もしかしたらなんかエラーが出てるのにそのままデプロイしちゃったかも?とおもってローカルで確認してみたけどそんなこと全く無い。。。
原因不明でした。
よくあるエラーと同じだった
今回の問題はDockerじゃなくてもローカルでも起きる問題が、Dockerコンテナをデプロイしたがゆえに発生した問題でもありました。
どういうことかというと、ローカルで普通に開発している場合(Dockerの有無にかかわらず)、Railsサーバーを落とした際に何かの不具合で tmp/pids/server.pid
が残っていると Process exited with status 1
が発生して起動できないことがあります。
これがまさに今回の原因で、コンテナをデプロイする際に、ローカルプロジェクトに tmp/pids/server.pid
が残っていると一緒にherokuへデプロイされちゃうと。
エラーメッセージがまさにそれを物語っていて
2019-09-04T01:35:25.823858+00:00 heroku[web.1]: Starting process with command `rails server -b 0.0.0.0` 2019-09-04T01:35:31.697033+00:00 heroku[web.1]: State changed from starting to crashed 2019-09-04T01:35:31.606898+00:00 app[web.1]: A server is already running. Check /myapp/tmp/pids/server.pid. 2019-09-04T01:35:31.608944+00:00 app[web.1]: => Booting Puma 2019-09-04T01:35:31.608946+00:00 app[web.1]: => Rails 5.2.3 application starting in production 2019-09-04T01:35:31.608948+00:00 app[web.1]: => Run `rails server -h` for more startup options 2019-09-04T01:35:31.608949+00:00 app[web.1]: Exiting 2019-09-04T01:35:31.684704+00:00 heroku[web.1]: Process exited with status 1
A server is already running. Check /myapp/tmp/pids/server.pid. で、デプロイはできているけど、processが既にあるんすわ〜ってherokuが認識してしまっていたということですね。
解決策
とても簡単で
$ rm tmp/pids/server.pid
$ heroku container:push web
$ heroku container:release web
これで解決です。
はまるところはあるんですが、一度出来てしまえばcontainerデプロイの便利さはやめられないです。
【レビュー】ロウヤの170度リクライニングオフィスチェアを購入した
どうもてぃです。
このたび、リモートワークが増える可能性があるということで、作業環境の整備をするはじめの一歩として椅子を購入しました。
願わくばハーマンミラーのアーロンチェアを買いたかったんですが、如何せん高い。
でも、アーロンチェアは会社で使っていてちょっとだけ不満もあったので、その不満を満たすべく自分の要望にあった椅子を探し求めた結果、今回の椅子に決めました。
以前使っていた椅子
実家にいた時に買ったのがこれ。
結果から言うと安物買いの銭失いでした。なんでこんなにレビューが良いのか謎なんですよねぇ。
このタイプ(ハイバックっていうのかしら?)の椅子、僕には全く合わなかったです。
主な理由としては、背もたれ。一息するとき、フーッと、もたれかかっても、身体にフィットしないというか背中全体を支えてくれない。
あと、もたれたときに背もたれが後頭部の高さまであるので、髪の毛にワックスをつけてると気になって安易に背中をつけられない、リラックスできないんです。
挙句の果てには半年で接続部分がもげてしまい、背もたれを外さないといけない始末。
現在は無様な姿と成り果て、粗大ごみとして出す機会を毎回失っているので、仕方なくギター用の椅子として使用しています。
今回購入した椅子
こちらです。
今見たらクソたけぇ。
楽天のスーパーセールで安くなっていたのですが、セール時に買い損ね残念に思っていたところ、公式を見たらたまたまスーパーセールよりも安くなっており衝動的にポチりました。
セール時には17000円くらいで購入できたのはラッキーでしたね。
使用し始めて3ヶ月ほど経過したので、良い点・悪い点を書いていこうと思います。
良い点
その1:組み立てが割と簡単
パーツがいちいちデカイのが難点ですが、デカイ分組み立ては結構簡単でした。
所要時間15〜20分ほど。
レビューで30分ほどかかると書いてたので、想定内に収まってよかったです。
その2:身体にフィットする
フィットします。前の子よりも断然いいです。
メッシュを購入して、高反発なのにフィットする。すばらC。
僕は身長180cmと割と大きめで、ハイバック式が嫌いという性質をもっていますが、リクライニングを調整すると背筋も伸びて頭も後ろにつかないし身体が包まれる感じがするのはマジで神です。
マジで神。
その3:腰が痛くならない
これも前述の通り、身体にフィットするので腰が痛くなりません。
僕の弱点は腰なので、これを満たせているはかなり大きいです。
つーか、椅子で腰悪くするって本末転倒だわ。
その4:リクライニング最高
仕事中に詰まったりちょっと休憩するときに、フルリクライニングできるのはマジで良い。
レビューにはありましたが、「この椅子に座ると眠くなる」はあながち間違ってないかも。
ただ、僕は仕事用に使ってるのでいまのところその兆候はないです。
フットレストもあって寝心地も割といい。でも、寝る用途として買ったわけではないので気をつけないとですね。
悪い点
その1:デカい
良い点でも上げてますが、デカいです。
僕は男性なので問題ないですが、女性だと一人で組み立てるのに苦労しそう。
あと、引っ越しの時割と面倒臭いかもしれないですねぇ。。。
その時はもっと稼いで、売り払ってアーロンチェア買おうかな。
その2:油臭い
新品あるあるなのかな?
到着してダンボールを開いた時に油臭く、組立後も一週間ほど油臭かったです。
組み立てるときにも思いましたが、接続部の部品(フットレストや足)に結構油がついてました。
仕方ないんですけどね。。。組み立て時にはちゃんと軍手をした方がいいです。
組立て終わった後にアルコール除菌シートで拭いてまわっても一週間前後は臭いが残ったので要注意です。
その3:各部品の品質が良くない
セール時の在庫処分的な商品だからかなーと思ったりしました。
品質については以下
- 座る部品のメッシュがちょっと破けてた
- ネジが合わず回すのに結構力が必要だった
- 左右で接続部の位置が違ったりする
- フットレストを出し入れするとき、何かに引っかかったりしてコツがいる
いまのところ気になるのはこれくらい。
上3つは時間も経ったのでもう気にしていないです。
ただ、フットレストは困りますね。毎回スムーズに出てこない。
しかも、出し入れの音がうるさい。
さらに、金属部分を触ると油が手に付く。
そんな頻繁にリクライニングして寝転がるわけではないので、いまのところ目をつむってます。
次買う椅子では必ず見るように気をつけたいです。。。
その4:フットレストうるさい
前述通りです。
出し入れがうるさいので、これは品質の問題。。。
次買う椅子では以下略
総評
以上、良い点・悪い点あげてみました。
前の椅子がひどすぎたのもあり、最低限要件が満たされている今回の椅子には総じて今のところ満足してます。
いや、その椅子はマジカスだよ、こっちのが絶対おすすめだよって人がいたら是非とも教えてください。
その時はあなたのアフィリンクを踏ませてください。お願いします。
【PostgreSQL】CloudSQLからエクスポートしたダンプデータをインポートする
どうもてぃ。
最近エンジニア用のアカウントを作成しました。
写真チャラいです。
それはさておき、本番環境と同じデータをローカルに反映させたかったので、DBサーバーのCloudSQLからダンプデータを落としてローカルにインポートしました。
その時の流れを書きたいと思います。
プロジェクトはRailsです。
CloudSQLからCloudStorageへ
使用しているDBデータをCloudStorageへ落とします。
ここに手順を書いてもいいですが、googleのドキュメントのわかりやすさには勝てそうにないのでそちらを参考にしてください。
以下参考。
ローカルへインポート
CloudStorageから上記手順で落としたダンプデータをダウンロードします。
その後、psqlコマンドでDB名を指定してインポートします。
この際、先にDBを作って準備しておく必要があります。要注意。
$ bundle exec rails db:create $ psql DB名 < ~/Downloads/Cloud_SQL_Export_2019~~~~~~~~~
ダウンロードしたダンプデータの保存先は基本Downloadsになっているはず。
違う場合はダウンロードしたパスを指定して上げてください。
ダンプデータのファイル名は上のように、 Cloud_SQL_Export_日付
になっているかと思うので、正しく指定してあげてください。
PG::ConnectionBad - fe_sendauth: no password supplied
準備が整ったと思ったので、サーバーを起動して画面確認したところ上記エラー。
単に database.yml
でパスワード設定してないだけでした。
おろかなり。
PG::InsufficientPrivilege - ERROR: permission denied for relation schema_migrations
パスワードを設定して、サーバー起動後画面を表示するとこのエラー。
使用しているユーザーがDBスキーマに対して権限を持ってないとのこと。
以下で解決。
postgres=> \c <database_name> # 権限を付与するDB名 database_name=> grant all on all tables in schema public to <user_name> # user_nameは付与するユーザー名
\z
で確認するとちゃんと付与されてるっぽかった。
マイグレーションを実行
$ bundle exec rails db:migrate ・ ・ ・ StandardError: An error has occurred, this and all later migrations canceled: PG::InsufficientPrivilege: ERROR: must be owner of relation <table_name>
まだ解決できない。。。
もっかい権限が付与されてるか確認してみると…特定のテーブルだけ権限が変更できてて、他は全く変更できてなかった。
\z
じゃなくて、\d
の方が見やすかった。だまされた。
なのでテーブルごとに権限を変更した。
postgres=> \c <database_name> # user_nameは付与するユーザー、old_user_nameは現在付与されているユーザー database_name=> select 'alter table ' || schemaname || '.' || tablename || ' owner to <user_name>;' from pg_tables where tableowner = '<old_user_name>'; # 上で出てきたものをコピーして貼り付け実行する
すべてuser_nameをownerへ変更できた。
解決
マイグレーションがやっと通りました。
CloudSQLから落としたデータをインポートするとこんなにハマるとは思ってなかった。
今後同じようなことが出てくると思うので備忘録として、また同じような作業をする人へ向けて書きました。
なにかわからないことがあればコメントよろしくお願いします。
【vim】color pickerを使えるようにする
どうもてぃです。
VSCodeやAtomでは標準で装備されてるcolor pickerですが、vimにはもちろんついてないです。
調べてみたら、普通にあったので導入してみました。
環境
- Ubuntu 16.04.5 LTS(elementary OS 0.4.1 Loki)
vCoolor.vim
こちらですね。
僕は dein.vim
をつかってパッケージ管理しているので、
" color picker call dein#add('KabbAmine/vCoolor.vim')
を追加するだけ。
github上のREADMEにオプションが書いてあるので、必要であれば追記してください。
注意
上記URLの説明にある通り、
- LinuxだとZenityもしくはYad
- Windowsだと colorpicker-windows-commandlineのプラグイン
- OSXだとruby scriptを使ったシステムのcolor picker
が呼び出されます。
Macの方は気にしなくていいですが、Linux & Windowsの方は気をつけてください。
完成
ノーマルモードで :VCoolor
と入力するとcolor pickerが呼び出されます。
呼び出すのを楽にしたいので後でキーマッピングしたいと思います。
では。
【Rails】helperで環境変数を使いたい場合
どうもてぃです。
備忘録として残しておきます。
環境変数を設定し、クライアント側で表示するものを変えたいとPMから要望が合ったので、その要件を満たすために実装しました。
実装したとはいっても、そんな大したことはやっていないですが。
実行環境
helperでは環境変数を読み込んでいない
まず前提として、helperでは環境変数は読み込めていないです。
今回、gemの dotenv-rails
を使っていますが、設定していた環境変数をhelperやviewで呼び出したのですが、 nil
が返ってきました。
module UsersHelper def display_user current_user.name if ENV['IS_USER_DISPLAY_DEFAULT'] == 'true' # => ENV['IS_USER_DISPLAY_DEFAULT']がnilで返ってくる end end
こんな感じ。
.env
ファイルに IS_USER_DISPLAY_DEFAULT
を設定している状態です。
解決策
至って簡単。
helperのメソッド内で読み込み直せば良い。
module UsersHelper def display_user Dotenv.overload current_user.name if ENV['IS_USER_DISPLAY_DEFAULT'] == 'true' end end
Dotenv.load
では環境変数を変更した際に再読み込みされないようなので、 Dotenv.overload
で対応。
これで面倒なクライアントさんの要件を満たすことが出来ました。
めでたしめでたし。
【Rails】docker-composeでrails generateが使えず、Could not find rake ~~~~になる
どうもてぃです。
もうそろそろ梅雨ですね。ジメジメしたのは嫌いです。
今回は docker-compose
を使って rails g controller
を行うと起こるエラーの対処方法について書こうと思います。
環境
- Docker version 17.12.0-ce, build c97c6d6
- docker-compose version 1.20.1, build 5d8c71b
起こったこと
いつもどおり、Dockerfileとdocker-compose.ymlを作成し、イメージのビルド、サーバーの起動まで上手くいきました。
以下がDockerfileとdocker-compose.yml
FROM ruby:2.5 ENV LANG C.UTF-8 ENV APP_ROOT /myapp RUN apt-get update -qq && \ apt-get install -y build-essential libpq-dev nodejs postgresql-client && \ rm -rf /var/lig/apt/lists/* RUN gem install rails WORKDIR $APP_ROOT COPY Gemfile ${APP_ROOT}/Gemfile COPY Gemfile.lock ${APP_ROOT}/Gemfile.lock RUN bundle install --path vendor/bundle ADD . /myapp
version: "3" services: db: image: postgres environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: root ports: - "5432" volumes: - ./tmp/db:/var/lib/postgresql/data web: build: . command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -b 0.0.0.0 -p 3000" volumes: - .:/myapp - ./vendor/bundle:/myapp/vendor/bundle:delegated - /myapp/tmp/cache - /myapp/log - /myapp/vendor - /myapp/.git environment: RAILS_ENV: development DATABASE_HOST: db DATABASE_PORT: 5432 DATABASE_USER: postgres DATABASE_PASSWORD: root ports: - "3000:3000" depends_on: - db tty: true stdin_open: true
ここにのせるとインデントがずれてますが、よくある構成だと思います。
上記の設定を元に環境を作ったあと、 rspec
を導入したかったのでいつものコマンドを入力しました。
すると。。。
$ docker-compose run web bundle exec rails g rspec:install Starting myapp_db_1 ... done Could not find rake-12.3.2 in any of the sources Run `bundle install` to install missing gems.
bundle installもうまくいくし、問題なさそうなのに Could not find rake-12.3.2 in any of the sources
が出てくる。
対処法
stackoverflowで全く同じ質問していた人がいたので、参考にしてみた。
$ docker-compose run web bundle install --binstubs # 自分の環境ではvendor/bundle配下に設置 $ docker-compose run web bundle install --path vendor/bundle
さて、ジェネレーターはちゃんと動くのか?
$ docker-compose run web bundle exec rails g rspec:install Starting myapp_db_1 ... done Beginning in Rails 4, Rails ships with a `rails` binstub at ./bin/rails that should be used instead of the Bundler-generated `rails` binstub. If you are seeing this message, your binstub at ./bin/rails was generated by Bundler instead of Rails. You might need to regenerate your `rails` binstub locally and add it to source control: rails app:update:bin # Bear in mind this generates other binstubs # too that you may or may not want (like yarn) If you already have Rails binstubs in source control, you might be inadverently overwriting them during deployment by using bundle install with the --binstubs option. If your application was created prior to Rails 4, here's how to upgrade: bundle config --delete bin # Turn off Bundler's stub generator rails app:update:bin # Use the new Rails executables git add bin # Add bin/ to source control You may need to remove bin/ from your .gitignore as well. When you install a gem whose executable you want to use in your app, generate it and add it to source control: bundle binstubs some-gem-name git add bin/new-executable create .rspec create spec create spec/spec_helper.rb create spec/rails_helper.rb Usage: rails new APP_PATH [options] Options: [--skip-namespace], [--no-skip-namespace] # Skip namespace (affects only isolated applications) -r, [--ruby=PATH] # Path to the Ruby binary of your choice # Default: /usr/local/bin/ruby -m, [--template=TEMPLATE] # Path to some application template (can be a filesystem path or URL) -d, [--database=DATABASE] # Preconfigure for selected database (options: mysql/postgresql/sqlite3/oracle/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc) # Default: sqlite3 [--skip-yarn], [--no-skip-yarn] # Don't use Yarn for managing JavaScript dependencies [--skip-gemfile], [--no-skip-gemfile] # Don't create a Gemfile -G, [--skip-git], [--no-skip-git] # Skip .gitignore file [--skip-keeps], [--no-skip-keeps] # Skip source control .keep files -M, [--skip-action-mailer], [--no-skip-action-mailer] # Skip Action Mailer files -O, [--skip-active-record], [--no-skip-active-record] # Skip Active Record files [--skip-active-storage], [--no-skip-active-storage] # Skip Active Storage files -P, [--skip-puma], [--no-skip-puma] # Skip Puma related files -C, [--skip-action-cable], [--no-skip-action-cable] # Skip Action Cable files -S, [--skip-sprockets], [--no-skip-sprockets] # Skip Sprockets files [--skip-spring], [--no-skip-spring] # Don't install Spring application preloader [--skip-listen], [--no-skip-listen] # Don't generate configuration that depends on the listen gem [--skip-coffee], [--no-skip-coffee] # Don't use CoffeeScript -J, [--skip-javascript], [--no-skip-javascript] # Skip JavaScript files [--skip-turbolinks], [--no-skip-turbolinks] # Skip turbolinks gem -T, [--skip-test], [--no-skip-test] # Skip test files [--skip-system-test], [--no-skip-system-test] # Skip system test files [--skip-bootsnap], [--no-skip-bootsnap] # Skip bootsnap gem [--dev], [--no-dev] # Setup the application with Gemfile pointing to your Rails checkout [--edge], [--no-edge] # Setup the application with Gemfile pointing to Rails repository [--rc=RC] # Path to file containing extra configuration options for rails command [--no-rc], [--no-no-rc] # Skip loading of extra configuration options from .railsrc file [--api], [--no-api] # Preconfigure smaller stack for API only apps -B, [--skip-bundle], [--no-skip-bundle] # Don't run bundle install [--webpack=WEBPACK] # Preconfigure for app-like JavaScript with Webpack (options: react/vue/angular/elm/stimulus) Runtime options: -f, [--force] # Overwrite files that already exist -p, [--pretend], [--no-pretend] # Run but do not make any changes -q, [--quiet], [--no-quiet] # Suppress status output -s, [--skip], [--no-skip] # Skip files that already exist Rails options: -h, [--help], [--no-help] # Show this help message and quit -v, [--version], [--no-version] # Show Rails version number and quit Description: The 'rails new' command creates a new Rails application with a default directory structure and configuration at the path you specify. You can specify extra command-line arguments to be used every time 'rails new' runs in the .railsrc configuration file in your home directory. Note that the arguments specified in the .railsrc file don't affect the defaults values shown above in this help message. Example: rails new ~/Code/Ruby/weblog This generates a skeletal Rails installation in ~/Code/Ruby/weblog.
rspecの設定ファイルは作成できたけど、なんかめっちゃ出てる。
要約するとbin関連をupdateしないといけないみたいね。ということでやってみた。
$ docker-compose run web bundle exec rails app:update:bin # 以下全てOverwriteする
bin関連でOverwriteするかどうか出てくるので全て上書きでおk。
終わりに
念の為、controllerが作成できるか試してみた。
$ docker-compose run web bundle exec rails g controller Home index
特にエラーも警告もなくコントローラー生成できた\(^o^)/
二回も同じことで躓いたので、流石にメモ。
安易にdockerに頼り過ぎないようにしましょうね。
【Linux】xargsに渡したファイルに空白がある場合の削除方法
どうもてぃです。
ちょっとだけハマったのでメモ。
ls, grep, xargs rm
上記のコマンドを組み合わせて、いつもどおり溜まったスクリーンショット画像を削除しようとしました。
すると。。。
$ ls | grep 'Screenshot' | xargs rm rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-05-08' を削除できません: そのようなファイルやディレクトリはありません rm: '16-39-46.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-03-14' を削除できません: そのようなファイルやディレクトリはありません rm: '18-18-42.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-04-18' を削除できません: そのようなファイルやディレクトリはありません rm: '10-37-00.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-03-12' を削除できません: そのようなファイルやディレクトリはありません rm: '22-42-45.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-03-07' を削除できません: そのようなファイルやディレクトリはありません rm: '18-41-14.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-04-16' を削除できません: そのようなファイルやディレクトリはありません rm: '20-19-58.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-05-06' を削除できません: そのようなファイルやディレクトリはありません rm: '18-28-44.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-03-01' を削除できません: そのようなファイルやディレクトリはありません rm: '17-38-51.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-03-12' を削除できません: そのようなファイルやディレクトリはありません rm: '17-43-33.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-03-06' を削除できません: そのようなファイルやディレクトリはありません rm: '10-59-12.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-03-26' を削除できません: そのようなファイルやディレクトリはありません rm: '10-35-37.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-04-28' を削除できません: そのようなファイルやディレクトリはありません rm: '16-34-29.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-04-04' を削除できません: そのようなファイルやディレクトリはありません rm: '11-03-00.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-02-08' を削除できません: そのようなファイルやディレクトリはありません rm: '15-21-58.png' を削除できません: そのようなファイルやディレクトリはありません rm: './Screenshot' を削除できません: そのようなファイルやディレクトリはありません rm: 'from' を削除できません: そのようなファイルやディレクトリはありません rm: '2019-01-25' を削除できません: そのようなファイルやディレクトリはありません rm: '14-15-28.png' を削除できません: そのようなファイルやディレクトリはありません
ん???!!!??!?!?
前やった時こんなのでたっけ?状態になりました。
他にも、 find . -name 'Screenshot*' | xargs rm
や find . -type f -name '*[Screenshot]*' | xargs rm
等も試してみましたが、ダメ。
結論
xargsコマンドは区切り文字に空白を使っているらしい。
つまり、空白の入ってるファイル名は別々のものと認識され、xargsに渡されてrmが実行されてしまうと。
そのため、区切りを空白文字ではなくnull文字で認識されなければいけないようです。
$ find . -name 'Screenshot*' -print0 | xargs -0 rm
xargsの -0
オプションの形式に合わせて、findコマンドで -print0
を指定してあげる。
これで解決しました。