cmd-wrapped
cmd-wrapped copied to clipboard
Why is mine 0?
me too
me too
@ATQQ @1017neroliu @80imike Can you show me the results of these commands?
echo $HISTFILE
cat $HISTFILE | tail - 20
@YiNNx me too
$ echo $HISTFILE
/home/dylan/.zsh_history
$ cat $HISTFILE | tail -10
sudo wireshark
nslookup hdslb.com
nslookup s1.hdslb.com
ip r
xrdp 192.168.100.215 Administrator
tail .zshrc
vim .zshrc
exit
nvim
exit
@ATQQ @1017neroliu @80imike Can you show me the results of these commands?
echo $HISTFILE
cat $HISTFILE | tail - 20
@YiNNx
echo $HISTFILE
/home/nero/.bash_history
cat $HISTFILE | tail -20
ls
bash cmd-wrapped
./cmd-wrapped
ls
cd ..
ls
rm ./*
rm -rf ./*
ls
unzip cmd-wrapped-linux-x86_64.zip
ls
cd cmd-wrapped-linux-x86_64/
ls
./cmd-wrapped
./cmd-wrapped 2022
clear
./cmd-wrapped
clear
clearexit
exit
I've figured out what the problem is. Zsh history won't keep track of the time for each command if the additional option called EXTENDED_HISTORY
isn't configured.(https://zsh.sourceforge.io/Doc/Release/Options.html#History)
Frameworks like oh-my-zsh can help set up this option, so initially I thought zsh would automatically timestamp each command when I wrote this cli.
If this option wasn't configured earlier, it's likely unable to retrieve the timestamps for historical commands, so as the history stats for cmd-wrapped. Sorry for that :(
I'm having the same problem, note that I'm using BASH and it's a server with multiple users in the home directory, I'm just one of them
I'm having the same problem, note that I'm using BASH and it's a server with multiple users in the home directory, I'm just one of them
As for bash, you need to set the $HISTTIMEFORMAT
to enable bash to keep track of the time for each command. This config will only work for the current user if you set it in ~/.bashrc
. Cmd-wrapped itself only analyzes history file for the current user, too.
I added the $HISTTIMEFORMAT
setting, and now I can output the timestamp of the command using the history command, but Cmd-wrapped still shows 0. Am I setting $HISTTIMEFORMAT
correctly 😂?
@YiNNx
@YiNNx the file is not empty
I'm having the same problem, note that I'm using BASH and it's a server with multiple users in the home directory, I'm just one of them
As for bash, you need to set the
$HISTTIMEFORMAT
to enable bash to keep track of the time for each command. This config will only work for the current user if you set it in~/.bashrc
. Cmd-wrapped itself only analyzes history file for the current user, too.
I am very sorry that I did not read the prompt information output from the terminal carefully when I used it. After I set the $HISTTIMEFORMAT, the time stamps of all commands changed to the current time, so I can only check the report of 2024
I added the $HISTTIMEFORMAT setting, and now I can output the timestamp of the command using the history command, but Cmd-wrapped still shows 0. Am I setting $HISTTIMEFORMAT correctly 😂?
@Freedom-Blue Well, this setting will enable bash to record the time from the time point you configure it, but the earlier commands' timestamps can't be retrieved. Maybe now you can view the 2024's stats...
I added the $HISTTIMEFORMAT setting, and now I can output the timestamp of the command using the history command, but Cmd-wrapped still shows 0. Am I setting $HISTTIMEFORMAT correctly 😂?
@Freedom-Blue Well, this setting will enable bash to record the time from the time point you configure it, but the earlier commands' timestamps can't be retrieved. Maybe now you can view the 2024's stats...
You're right, I can only look at 2024 data after I set it up 😂,Thanks for the pointer!🤞
Already add a note for this in README.
I got a "zero", too. What's different is that my historty seems to use the Unix timestamp instead of ISO 8601
got it, seems that oh-my-zsh
hadn't help me to set EXTENDED_HISTORY
on my OS……
I got a "zero", too. What's different is that my historty seems to use the Unix timestamp instead of ISO 8601
It seems like your history file is correctly recording the timestamp. 🤔 The output should not be zero. What about the result of 2024?
It seems like your history file is correctly recording the timestamp. 🤔 The output should not be zero. What about the result of 2024?
That's so weird that on all my three machines, only the latest few commands have the timestamp whenever. Maybe some NixOS magic or so on, I will enable HISTORY EXTEND
and re-test it after few month.
Mannally adding fake timestamps for test works for me.
That's so weird that on all my three machines, only the latest few commands have the timestamp whenever. Maybe some NixOS magic or so on, I will enable
HISTORY EXTEND
and re-test it after few month.Mannally adding fake timestamps for test works for me.
:ok_hand: Got it
Mine is 0, too. I use oh-my-zsh, and a custom HISTFILE like this (set in .zshrc)
HISTFILE=~/.histfile
HISTSIZE=1000000
SAVEHIST=$HISTSIZE
And this histfile has thousands of lines of cmd with timestamp(earliest is around 2022), but it's still 0;
I think you are right. Judging from history.rs, the HISTFILE
seems to be hard-coded (I didn't check other codes though):
https://github.com/YiNNx/cmd-wrapped/blob/18119a892471a06bf9761ebd06e189f34509c9ef/src/history.rs#L36-L61
If you set a filename other than .zsh_history
/.bash_history
, the program would simply panic.
For a temporary fix, you can create a symlink to the real HISTFILE
so that it can be recognized (and you can delete it afterwards, just note to backup in case you accidentally delete HISTFILE
...):
# Ensure to change the file path and name
ln -s ~/.histfile ~/.zsh_history
cmd-wrapped 2023 -s zsh
# It should work now
For a well-rounded fix, I think @YiNNx could add support for reading HISTFILE
and preferring it over the hard-coded path.
Never mind, did not notice #17 just now, it should be solved with the upcoming -f HISTFILE
parameter...
@Vinfall Now fixed by #18. Thanks for the suggestion!
I initially used the hard-coded path because the $HISTFILE variable couldn't be accessed directly through env::var()
, which left me confused and replaced it with the hard-coded path. Thanks to @aeghn, it turns out that the variable should be read in the shell session, and now the problem has been gracefully resolved.